bump :)

Thanks AllanR , appreciate the response!

I've still got a bit of work to do to confirm if it's fixed but I think you've nailed it :)

If I'm still having an issue I'll come back with a capx lol

I'm making an RTS style game which the player can use the mouse to drag the viewport around the layout and use the mouse wheel to zoom in and out.

I have a background layer which doesn't scale but has 50% parallax. I've been having problems when scalling the foreground because when you zoom in and out the parallax effect was changing even though the values stayed the same (Zoomed out = lots of offset, zoomed in = hardly any).

To fix this I've multiplied the parallax values by the foreground layer scale, foreground has 1.5 scale = background has 75% parallax, foreground has 0.5 scale = background has 25% parallax. This kind of worked and it doesn't matter if I'm zoomed in or out the parallax is consistent.

However when I zoom in and out the position of the background changes because the parallax values are changing in realtime. The background travels diagonally down and right when zooming out and up and left when zooming in, unless you're right in the top left corner where the pararllax is centred.

From what I've found on the forums so far this is as close as I can get to what I want:

For every mouse wheel movement, set the background X position to:

X+(scrollx-ViewportWidth/2)*LayerParallaxX/100

and the same again for Y.

This gives me the effect I want, consistent background parallax and only the foreground scalling up/down without the background moving diagonally. Great! Except the background now jumps to a position relative to the viewport when I start zooming (So instead of the background moving diagonally with every mouse wheel movement, it moves once every time the viewport is moved to a different part of the layout).

Is layer2canvas and canvas2layer the way I should be positioning the background x/y values instead of the above equation? I couldn't figure out to do it... Hoping someone who can actually do maths can help :)

Thanks in advance!

p.s. I'll sort out a capx when I get the chance

Whooo lag :D

Getting a 404 on that link - Any chance someone can fill me in?

Cheers!

Good question dop2000 How did I not see that lol >.< Thanks for all your help!

— Any idea how I can change all the "full" values to "sand", or "grass" or well... anything else all at once? I fear I should of done it a cleaner way first time around and now I want to edit it I'm up a certain creek without a paddle!

(Its a 256x32x32 array, there's a lot more events with the exact same actions that need to be changed as well.... aprox 120ish)

dop2000 OddConfection thank you both so much, you've just saved me days of work ^_^

The layout is fairly big, much bigger than the viewport/window anyway. As you say dop2000 - the player has the scroll to behaviour and the HUD is on a separate layer with 0,0 parallax and the anchor behaviour. So when the player moves, the HUD moves with them. My HUD has been set up as a black border surrounding the viewport/window - Like a screen within a screen, kind of like this: rpgmaker.net/media/content/users/15964/locker/top_hud2.png

This means when the HUD reaches the edge of the layout and stops, there is about 1000 pxls which can't be seen, but are still there....

At the moment I'm busy trying to add this space the HUD covers with a border which will act like the edge of the layout but it's time consuming, to say the least!

I have created a touch gamepad for mobile players but it has made the HUD a border around the screen. This has led to a bunch if issues, the root of the problems lie with the fact the HUD border renders the edge of the map inaccessablie unless you walk under the HUD.

First port of call was to make the HUD act like the edge of the layout but the actual edge of the layout is still inaccessible, which is a total deal breaker for my randomly generated terrain. I thought about adding that extra space to the layout and making a border for the layout to match the HUD but every sprite placement is heavily reliant on the background tiles starting at 0,0.

It's going to take me while to recalculate the layout generation so if anyone has any nifty suggestions in the meantime I'm all ears...

newt Thanks! You've pointed me in the right direction.