flip-screen scrolling and lerp

Hi, I'm wanting to make a flip-screen system similar to old games such as Prince of Persia, Flashback etc whereby single screens are displayed until the player ventures to the edge at which point it flips to another screen - the thing is I don't want an abrupt jump, I want to scroll the screen to the next point.

I've set up a camera object with the scrollto behaviour and figured I would hardcode some values and move the camera with lerp when the player was in the correct area of the screen. The thing is it's not behaving the way I expect it to, if you look at the attached capx you'll notice that I've hardcoded the camera to move to 960 pixels if the player x is greater than 640 - but it never gets there, it always stops at 941 pixels! Can anyone tell me why this is happening?

capx here

Also, if there's a more elegant way to achieve this effect without hardcoding a bunch of coordinates I would love to hear it! Thanks for any help.

Problem seems to come from using the floor() expression.

Remove that and it works.

example without hardcoding

Thanks for the example, it has taught me some new things - any idea why the floor expression isn't working though? If anything I thought using it would be more accurate!

The common use of Lerp actually hides what the math is doing. LERP is a linear interpolation between two values, where a decimal number between 0 and 1 describes how far along the scale the value lies.

So, for example,

if you scale is 0-100, a value of .3 indicates that the value should be 30. Percentages! But of course, we can use other scales, so a scale of 654 - 1782 with a interpolation value of .3 is 992.4.

It works out to:

(high - low)* interpolation + low.

Now, the common use in Construct 2 is to achieve a smooth curve approach to a value, such as a camera target. That way the camera smooths into the value, rather than having an abrupt end. If we look at the math:

Say we had our 0-100 example, with the .3 interpolation value.

First loop:

0-100, .3 gives 30. So we set position of the camera to 30.

Next loop:

30-100, .3 gives 51. So we set position of the camera to 51

51-100, .3 gives 65.7.   So we set position of the camera to 65.7.

Etc...

Now, what ends up happening is that eventually the camera is moving by very small steps per step of the logic. But we are feeding the result of the previous step back in as into the logic to get the next step. Eventually, the camera starts moving by less than an integer per frame, which means that if you floor that value, it stops moving entirely, because every time the floor is causing it to reset the value to what it was. (going from 941, to 941.87, which gets floored back to 941, in your case, for example)

Now, it is a good idea to have an end condition for the move, to prevent small minute "drifts" of the camera. This can be achieved by having a condition to check if the distance between the camera and the target is less than some critical distance. If it is, snap it to the end value. Too much and you'll see the snap, too little and you'll get minute pixel shifts of some of your sprites, particularly if they have non-integer positions.

Hope that helps!

Thanks heaps for a very detailed and useful explanation! That helps a lot!