2
\$\begingroup\$

So, we're working out our interpolated render-coordinates during our render call and it's doing a fantastic job of smoothing everything out. All is great and collision detection is working to a perfectly acceptable level (for simple CD - ie, player hits other object, looses a life, starts over...).

However, how do we deal with situations that require 'collision and resolution'? The classic example, of course, being our player character colliding with a solid object (usually a platform or the ground) and then being 'resolved' to bring the 2 entities out of collision.... here is what I mean:

enter image description here

Even if we say something simple like 'just don't interpolate vertically when touching a platform' - that wouldn't seem a very clean solution because we need to think about slopes where the player is moving both left/right as well as up/down.

What is the easiest and cleanest way to protect ourselves from this happening?

\$\endgroup\$
9
  • \$\begingroup\$ If you already have the infrastructure to make exceptions for the interpolation part, why not "don't interpolate when a collision resolution has taken place"? \$\endgroup\$
    – Panda Pajama
    Commented Sep 11, 2014 at 2:23
  • \$\begingroup\$ Well @PandaPajama lets take my slope example. The whole point of doing the interpolation is to keep my sprite movement smooth. So lets say I'm walking up or down a slope (or sliding down a slope) Now, during this action we wont be interpolating, therefore, the sprite would be subject to choppiness as we wont be interpolating it (as character would be in collision with the slope), which defeats the whole point of introducing interpolation in the first place if you see what I mean. \$\endgroup\$
    – BungleBonce
    Commented Sep 11, 2014 at 11:48
  • \$\begingroup\$ Actually I don't. I don't understand the reasoning behind interpolating the rendering. In any case, when interpolating, you will always have incomplete information, and therefore will have cases in which your interpolated results won't match what's happening in the world. \$\endgroup\$
    – Panda Pajama
    Commented Sep 11, 2014 at 11:51
  • \$\begingroup\$ I still don't understand why you think an interpolated rendering will have better chance of making it to the vSync deadline than a non-interpolated rendering, and how can you know that -before- you begin rendering (so you can choose whether or not to interpolate). Sorry to give a different opinion, but if you're having trouble with dropped frames, and no dropped frames is a requirement of your game, then you should work on fixing that instead of trying to make solutions that will probably just make the problem worse. \$\endgroup\$
    – Panda Pajama
    Commented Sep 11, 2014 at 12:05
  • 1
    \$\begingroup\$ Ah no, I agree, performance won't be better that's for sure, however 'perceived' performance is better, if I run my interpolated game next to my non-interpolated game, the difference is startling:-) unfortunately I can't envisage a gameloop that will run perfectly on every device out there without using some form of interpolation / visual correction. That being said I would like to hear your thoughts on my game loop(s) implementation - I will post a question at some point and comment here so you can take a look :-) \$\endgroup\$
    – BungleBonce
    Commented Sep 11, 2014 at 13:30

2 Answers 2

Reset to default
1
\$\begingroup\$

The physics engine should not report the player's position within the platform. Collision detection and resolution are both part of a single physics simulation time step.

Your rendering lerp function will not have this this problem if it is correct. Again, this is because the physics engine should have resolved the player's correct position after collision detection, all before the render logic takes over.

\$\endgroup\$
7
  • \$\begingroup\$ Hi @WilliamMorrison, thanks for the answer. However, as you can see from my diagram, my logic is resolving collision (steps 1 & 2) within one logic update, so, when it gets to render(), the object is reported as sitting nicely on the platform (not in it). However, the lerp function would then alter the object position for rendering purposes. This is where it gets rendered. Would it help if I posted the code I'm using to interpolate between old and current positions? Or maybe you could expand you answer to with a diagram or example to show what you mean if I've misunderstood. Thanks! \$\endgroup\$
    – BungleBonce
    Commented Sep 12, 2014 at 23:44
  • \$\begingroup\$ Yeah, the lerp function might help, I don't expect to see problems there though as its simple. Is the player being rendered hovering above the platform when the player is at a rest? \$\endgroup\$
    – William Morrison
    Commented Sep 14, 2014 at 0:46
  • \$\begingroup\$ You're absolutely right @WilliamMorrison, I've been over my code and I've realised that there was indeed a problem. The problem now should be resolved. It was an issue with previous and current positions. Now though lerping, effectively stops when the player hits a platform. The first time, lerp will do it's thing, but on subsequent occasions, the difference between the old and new position will be 0 so no lerping happens!! Thanks! \$\endgroup\$
    – BungleBonce
    Commented Sep 15, 2014 at 22:28
  • \$\begingroup\$ There still, however, remains the issue of lerping a player going up or down a slope - as far as I can tell, the same logic can't be applied in cases like these because the player is moving left/right and up/down, so the lerping will never 'stop' - in these situations, my character is actually being rendered above or slightly embedded in the slope tiles. However, I will say that for this question, the basic problem for horizontal or vertical collision has been resolved. I'll open another question for sloping and will link it from here if you could take a look - thanks \$\endgroup\$
    – BungleBonce
    Commented Sep 15, 2014 at 22:31
  • \$\begingroup\$ @user22241 Yeah, sure thing. Glad you figured it out! Interested to see the next question. \$\endgroup\$
    – William Morrison
    Commented Sep 16, 2014 at 13:34
0
\$\begingroup\$

The case of your problem is that the time of collision (as know as time of impact, TOI) does not match the time of current neither next frame. In fact, any collision potentially can happen between two render frames. All you can do is only to cheat and pass not a real time, but a TOI to your lerp function.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .