Why is interpolation passed into the rendering routine when the position and speed are related to the update routine?

Question

I've read this in several well known articles, including this one:

http://www.koonsolo.com/news/dewitters-gameloop/

Under the Interpolation and Prediction subheading is the description of the formula. I'm currently using the suggested game loop from the article (without passing in the interpolation). I get why interpolation is used, but I'm having trouble understanding why it is applied during rendering, and how it relates to my game.

I'm presently using pure tile based movement for 32x32 tiles. So my player moves from tile A to tile B so long as tile B can be occupied, and at a fixed rate of 1 pixel per 10ms. The state is "walking" until the player moves the full 32 pixels, at which point the state is "stopped". This all happens in a standard timer, but all during my update routine. My rendering routine simply takes the player's position and renders it onto the map. There is no "speed" per say in that equation that is accessible. So how would I use interpolation?

Answer 1

Combining a physics engine that uses a fixed time-step with a variable-timed rendering loop can lead to very choppy movement. Sometimes you have two physics frames between two renders, sometimes none at all and you render the same thing twice. This can lead to choppy movement and scrolling.

The solution to that is to pass not just the current but also the last game-state to the rendering engine and a delta-time variable that states how many milliseconds the current game-state is in the past. That allows the rendering engine to either interpolate or extrapolate object positions accordingly, which results in much smoother movement.

For example:

• Last tick: object was at horizontal position 3.0
• Current tick: object is at 5.0
• Time information: We are 30% between current tick and the next tick

When the rendering engine uses extrapolation, it would calculate that the object is moving with a velocity of 2.0 units per tick, so it now draws it at 5.6 units. When the rendering engine uses interpolation, then it will linearly interpolate between the last and the current tick and place the object at 3.6 units.

But because the player has a pretty good gaming rack, just a few millisecond later the frame is finished and we want to draw another one. Time advanced to only 70% to the next physics frame. So we draw the object at 6.4 (extrapolation) or 4.4 (interpolation).

As you can see, passing timing information to the rendering engine allows us to give the impression that the game runs with a much higher physics framerate than it actually does, resulting in much smoother rendering.

Answer 2

That article seems to be written around a variable framerate. This is okay for rendering, but many parts of a game are time-dependent (want to avoid huge jumps in time). Variable framerate is especially bad for physical simulation. To avoid such issues most parts of a game can be updated at a fixed timestep, while rendering can be updated at maximum FPS.

You take previous positions from the game, and current positions and interpolate between the two to form a smooth animation for animating the sub-steps between two simulation loops.

If you want more detail I wrote a better article here. See the section on time stepping.