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

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?

• The idea is to run your game simulation at a fixed time step in all situations, while rendering does the interpolation based on an object's current (or target) position and velocity. This post may answer some of the questions: learn-cocos2d.com/2013/10/… Dec 15, 2013 at 17:23
• I'm sorry to be so dense about this, but can you define "fixed time step"? I've read the terms variable and fixed time step, but don't quite understand simply what a time step is.
– user6214
Dec 15, 2013 at 22:07
• Some of the problem may also be that I have no separate field for velocity. I'm moving the length of a tile (32 pixels) at a presumably fixed rate. If instead I did have a velocity integrated it might make more sense to me.
– user6214
Dec 15, 2013 at 22:20
• I once worked on a PS2 game where we did exactly this so that the rendering could draw objects at slightly different positions on odd-numbered scan lines than on even-numbered ones. The television's interlaced video signal gave us the appearance of 60fps rendering when we were actually only rendering at 30fps. With modern televisions you can't do this trick any more, but it was a neat hack at the time. Dec 15, 2013 at 23:54

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.

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.