Interpolation gives the appearance of collisions

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.