I'm implementing a simple 2D platformer with a constant speed update of the game logic, but with the rendering done as fast as the machine can handle. I interpolate positions between actual game updates by just using the position and velocity of objects at the last update. This makes things look really smooth in general, but when something hits a wall/floor, it appears to go through the wall for a moment before being positioned correctly. This is because the interpolator is not taking walls into account, so it guesses the position into walls until the actual game update fixes it. Are there any particularly elegant solutions for this?

Simply increasing the update rate seems like a band-aid solution, and I'm trying to avoid increasing the system reqs. I could also check for collisions in the actual interpolator, but that seems like heavy overhead, and then I'm no longer dividing the drawing and the game updating.


3 Answers 3


Don't interpolate with velocity. Calculate the next actual position ( with full physics ) and simply interpolate between the last and current positions. Same for rotation and any other physical properties that graphics cares about.

What might happen now is that an object bounces before hitting the floor, but if you keep your objects at reasonable speeds you probably won't notice is much.

Also try to run physics around as often as graphics. A lot of physics engines run at over 60hz ( and there's basically zero reasons to run graphics faster than the monitor's display rates aside from benchmarking ).

  • \$\begingroup\$ If I'm understanding correctly, rather than guessing the future, I ought to just display what is slightly past? Just to make sure I'm on the right page, I'll essentially have to hold two entire game states in memory at once then? \$\endgroup\$ Jun 10, 2012 at 2:57
  • \$\begingroup\$ Implemented it (fairly simple), and it worked beautifully! I'm admittedly still thinking about the overhead of storing two game states at all times, but I guess it's probably not that much, and if it's an issue, it's easy enough to only interpolate for the player character (since that's what's doing the most movement that you're staring at). Thanks so much! \$\endgroup\$ Jun 10, 2012 at 7:25
  • \$\begingroup\$ You don't need two game states. Just the physically modeled bits that graphics cares about. In many simpler games, this is position and maybe rotation. You can often fake the rest. \$\endgroup\$ Jun 10, 2012 at 8:18

So you're extrapolating? This problem reminds me of netcode in 3D shooters: The client has to "predict" its own collisions with walls, to avoid being placed back later by the server.

If you're dead set on not coupling game world updates to render updates, the only option would be to "predict" collisions in your view/renderer logic, as you kind of suggest in your post. You'd still have the separation of the actual game state and the game "view", though.

If you regard your design as client-server, it's actually not bad: The game update loop is the server, and the client is the view/renderer, which predicts movement, including collision. However, it does introduce a set of potential problems usually present in realtime client-server game architectures...

Some potential issues

Depending on your game, you'll also have to predict things like enemy/projectile collision and f.e. as a result, have a rocket explode, do damage, and kill an enemy before all this actually happens in the next game update.

Second, since you'll probably want the game to respond immediately to player input (otherwise it feels weird), you might want the player character to start a jump somewhere inbetween 2 game updates. The same goes for firing projectiles. Are you going to initiate these actions on the server on the next update? Or will you get the projectile's position from the view, breaking the separation of game updates and view?

What if an early, predicted projectile hits an enemy and predicts its death, but is avoided in the next game update because the actual projectile is fired later?

One option is to wait for 2 game updates and interpolate instead of extrapolating. Drawbacks are the artificial delay in view, and the problem of having to make player movement instantaneous, predicting it, resulting in displayed player actions being in the future, relative to the rest of the world, which introduces its own set of problems...

Final thoughts

As you can see, de-coupling game updates from rendering introduces potential problems. Depending on the nature of your game, these may or may not be dealbreakers. Post an update sometime, I'm curious how your approach turns out, whatever it may be.

  • \$\begingroup\$ Lots of big thoughts on this with little knowledge of how this is actually done. \$\endgroup\$ Jun 10, 2012 at 2:28
  • \$\begingroup\$ My statements are facts and I also mention interpolating as an option (including associated problems), but I suppose your answer is better, focusing on that approach as a solution. \$\endgroup\$
    – Torious
    Jun 10, 2012 at 9:02
  • \$\begingroup\$ Your statements about "predicting collisions" in the renderer are where you went astray. It is not at all a fact that "the only option" is to do that, and absolutely no sane game engine does do that. Your entire answer is pretty close to being a correct answer for a multiplayer client/server design, but has no relevance to a single player game that's interpolating fixed time-step physics while using a variable frame rate renderer. \$\endgroup\$ Jun 10, 2012 at 21:54
  • \$\begingroup\$ +1 point for being the only responder who identified that the original poster is describing extrapolation, not interpolation. \$\endgroup\$
    – Justin
    Oct 4, 2012 at 20:54

Your problem stems from that you are interpolating between the current frame, and the next (future) frame. As long as your game logic is updating at a reasonable rate you could simply interpolate between the last frame and the current frame, ie delaying the display of the graphics with 1 game tick. This way it can interpolate between two known states instead of between a known and an unknown state.

The obvious downside is that game input is delayed, but if your game logic updates at 60fps you would only delay it with 16ms. If you also have a slight acceleration to the movements of the characters you can minimize the impact of this delay.

It seems that you are spending a lot of effort on enabling the game to look smooth while using low update frequencies though, perhaps making the game logic able to update at variable rates would be easier.


You must log in to answer this question.

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