# Lerping character moving up and down slope tiles

So, when interpolating position against a standard 'horizontal' platform, everything works great. What happens is something like this..... (Question continues after graphic)

Now, the question I have is, how do we correctly interpolate the player's sprite (blue circle) against a 45° tile? When I attempt to do this, what happens, is that when the player is going up the slope, it is slightly embedded in the tile and when coming down the slope, it floats slightly above the tile.

In the example above, the sprite effectively 'stops' moving along the Y Axis, so therefore, interpolation along that axis stops, however when interpolating the position against a slope, the sprite moves in an X and Y direction, so never stops. I think this is causing the issue, if my logic is correct, some more graphics follow to illustrate what I mean....

What am I doing wrong? How do I interpolate my sprite while making sure it's 'on' the slope at all times?

For moving up a slope

When moving down slope

Summary

When interpolating against a horizontal platform, although the sprite isn't rendered on the platform in the frame straight after collision has been resolved, it is rendered on the platform during subsequent frames because the difference between the old and new positions has become 0 as it is no longer moving. However against a slope, again, the initial frame is incorrect but then the sprite moves again, so the next frame is also wrong etc so it never 'settles'. Note it does move at the slope's angle just not on the slope.

I'm trying to work out how to get my two points along the 45° slope and interpolate between them (ie, along the slope)....

Without checking if your player is inside a platform in your render logic, you cannot prevent this.

You can mitigate this by minimizing the distance the player moves between physics updates. This is accomplished by limiting the player's velocity (duh.) This helps because the less distance you interpolate over, the less you're assuming about the player's path between updates.

All this makes a lot of sense right? All you have is a bunch of points you know are correct, and you're just guessing at the path between points. The more distance between those points, the more error prone your guess will be. Working on a better interpolation routine isn't going to help much, because any interpolation is, by definition, a guess. That leaves either just guessing, as you are now, or running collision logic to get the correct position.

If you insist on running collision logic in your render routine, look into calculating the minimum translation vector. This is all you need to shift your player outside the bounds of the ramp. Running collision logic twice might be ok CPU-wise for a single body. Although it is still violates separation of concerns, a common software design guideline, as your display (render routine) will be dependent on your logic (physics system.)

If you try simulating many bodies like this, you will waste a lot of CPU. I do not suggest this approach for many bodies.

Edit:

Here's the only issue I see you having. If drawing a line as thick as your player between 2 physics updates would cause the player to intersect a platform, linear interpolation could put a player in a platform.

The problem you're describing above, of the player floating above, or appearing in a platform should not happen if your code is correct, and something similar to my illustrated condition does not occur.

So, I think your code is incorrect, likely in the render routine. Maybe your player graphic isn't aligned with the physics coordinates correctly? Maybe your linear interpolation is a little off. Maybe your physics object is a little smaller or bigger than your player graphic?

Regardless, I don't think the problem is with your interpolation. If you want more help, post code. We've gone as far as we can with what you've provided.

• Luckily this is only for 1 sprite, but I wonder, lets say I have 2 points along a 45° slope, surely there must be some equation to 'guess' or 'interpolate' the position along that slope no @WilliamMorrison? There must be a way to do this surely? :-( Otherwise it's double collision for me and I really don't like this fix, it seems like a hack. I'm wondering how commercial games get around this when they interpolate. Sep 19 '14 at 14:28
• I don't know how commercial games handle this, I'd guess they allow some invalid penetration of objects in the render routine. Yes, you can find an interpolation routine which works along a 45° slope, but how will you know when to use that routine, or linear interpolation without having your render logic aware of physics? Any interpolation ignorant of your physics logic will always fail in some cases. Sep 19 '14 at 15:50
• Well @WilliamMorrison, to be honest, I have a way of setting a boolean such as 'inContactWithSlope' so knowing when to use it wouldn't really be a problem - do you know the maths behind such interpolation or any source on the web somewhere where I can read up on this? Also, if the slope is at a constant angle, that would surely still be 'linear' by definition? Thanks, I find this interesting but even more interesting that there doesn't seem to be any info out there that I can see.... Sep 19 '14 at 18:06
• Yeah, I misunderstood your problem. Please link to your project, I think that's the only way this is going to be resolved. Sep 19 '14 at 18:55

I think you should interpolate between two collision resolved frames. If so, the ball would touch the slope because the linear interpolation of two frames where the ball touches the slope would produce a ball, center of that is lying on imaginary line that connects the centers of two balls at collision resolved frames. This is true, if the slope is linear.

So, you need to:

• Update ball speed. It would change due to the gravity or user input.
• Update ball position.
• Resolve collisions.
• Back up frame.
• Render interpolation of the two last backed up frames.
• Hi @Podgorskiy, I just want to clarify that the 'ball' in the example is, in reality a 'player character' say , ike Mario. I dont want the ball to 'bounce' off the surface, but rather I want it to simply climb up the slope along the slope's surface. Not sure if you misunderstood the question or if I misunderand your answer. Perhaps you could add some diagrams to illustrate what you mean, as I'm not sure I get it. Thanks :-) Sep 18 '14 at 23:39
• Currently without interpolation it works OK (ie, climbs up/down the surface of the slope) but when I interpolate, although it still climbs up/down the slope, it's not 'on' the slope, it's either embedded or just above it, depending on direction. Sep 18 '14 at 23:55
• @user22241. I've updated my answer. Yes, you were right, I didn't understand you correctly at first, I thought, that the ball has more physical behavior. Sep 19 '14 at 0:12
• Hi @Podgorskiy, thanks, but am I not doing that already? I back up the position, move (resolve collisions if need be), then interpolate (and render at interpolated coordinates which is between previously backed up coordinates and current coordinates), then start the cycle again by backing up the current coordinates (so they become the old coordinates) and so on...... it works brilliantly for just moving and also for colliding against walls and platforms, but not for slopes.... Sep 19 '14 at 0:26
• Again, if you could show some diagrams in case I've misunderstood it would be helpful, thanks Sep 19 '14 at 2:17

I finally found out what was happening and the solution was actually really simple.

In my logic update, I was stepping Y first (applying gravity etc) and then moving my characters along the X. (This worked fine for levels with no slopes).

The solution was simply to reverse this.

For example, when stepping Y first, the sprite was being pushed down into the slope, and resolved to sit on it, then the sprite was moving out (X) and this was where it was being rendered - away from the platform.

See The guide to implementing 2D platformers for the article which led me to the resolution. See this quote from the above article:

Decompose movement into X and Y axes, step one at a time. If you’re planning on implementing slopes afterwards, step X first, then Y. Otherwise, the order shouldn’t matter much.

So for anyone who may be experiencing similar problems, remember, when you have slopes in your game, it's important to step X first, then step Y. After doing this (at least in my case), the sprite adhered perfectly to the slope. It was never an issue with the interpolation as I initially thought.