Lerping character moving up and down slope tiles

Question

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)....

Answer 1

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.

Answer 2

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.

Answer 3

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.