Problem with scrollx, scrolly when using ScrollTo behavior

Hello Scirra community,

I made a template that helps developers easily add parallax backgrounds to side-scrolling games. Check it out here : https://www.scirra.com/store/royalty-fr ... ounds-1289

The template computes each background's position and width from the scrollx and scrolly system parameters.

The backgrounds move nicely as you can see in this video : https://youtu.be/0YkXoFELqWE

There is however one limitation you have to comply with : if you scroll the layout, you have to do it before including the event sheet where I implemented the parallax effect. That way, the parallax effect will always use the newest values of scrollx and scrolly (system expressions).

The problem with this implementation is that if you add ScrollTo or MagiCam behavior to a sprite, my parallax effect will use the old values of scrollx and scrolly every tick to compute the backgrounds' position and width. This will cause the backgrounds to move in a jumpy way.

What I advise my clients to do is to remove the ScrollTo behavior, then manually scroll to the sprite in the event sheet, then include the parallax effect's event sheet after this event and any event that modifies the layout's scrollx and scrolly.

Is there a way to have my parallax algorithm always use the newest values of scrollx and scrolly no matter where I include it in the event sheet? It would also be great to keep using ScrollTo or MagiCam behavior while still getting the newest values of scrollx and scrolly.

If you experienced a similar problem previously, could you suggest a solution? My clients and I would really appreciate it! Thank you.

Did you not use the existing system parallax?

newt No, the existing parallax effect for layers is centered at the top-left corner of the layout, which is not intuitive for side-scrolling games such as platformers where almost all backgrounds are positionned on the ground (mountains, hills, ... etc).

I compute the coordinates of each TiledBackground instance myself using the layout scrolling value provided with the system expressions scrollx and scrolly.

My implementation centers the parallax effect at the bottom-left corner of the layout.

By looking at the code of the ScrollTo plugin, I see that it scrolls the layout in the "tick2" method, which is called after the events in the event sheet apparently. So my event sheet will always have the old scrollx and scrolly values, which in turn create the one-frame lag.

Best bet would be to implement your own camera using a system variable set to use your parallax offset in an everytick event.

Scrollto is nothing but scrollx, and scrolly with some interpolation for instances.

newt Yes that's the solution I use and tell my clients to use. However, I wish there was an easier way to get scrollx and scrolly after they are modified by the ScrollTo behavior.

They aren't modified.

The scrollto behavior is last in events.

Scrollx, and scrolly can be any position.

That is to say within the constraints of the layer boundary if its turned on.

newt That's exactly my problem right there. Because ScrollTo behavior updates the system's scrollx and scrolly after all events, my events always use the old values of scrollx and scrolly in the current tick. Thus creating a one-frame lag.