Consider the following scenario:

Let's say, for sake of example and simplicity, that you have an authoritative game server that sends state to its clients every 45ms. The clients are interpolating state with an interpolation delay of 100 ms. Finally, the clients are rendering a new frame every 15ms.

When state is updated on the client, the client time is set from the incoming state update. Each time a frame renders, we take the render time (client time - interpolation delay) and identify a previous and target state to interpolate from. To calculate the interpolation amount/factor, we take the difference of the render time and previous state time and divide by the difference of the target state and previous state times:

var factor = ((renderTime - previousStateTime) / (targetStateTime - previousStateTime))

Problem: In the example above, we are effectively displaying the same interpolated state for 3 frames before we collected the next server update and a new client (render) time is set.

The rendering is mostly smooth, but there is a dash of jaggedness to it.

Question: Given the example above, I'd like to think that the interpolation amount/factor should increase with each frame render to smooth out the movement. Should this be considered and, if so, what is the best way to achieve this given the information from above?

  • \$\begingroup\$ Prehaps you could extrapolate by allowing the factor to become greater than 1? \$\endgroup\$ Commented Jul 1, 2013 at 13:01
  • \$\begingroup\$ It crossed my mind, but I do not have extrapolation implemented and would prefer to solidify/optimize my interpolation before moving forward. \$\endgroup\$
    – J.C.
    Commented Jul 1, 2013 at 13:14
  • \$\begingroup\$ maybe you are overengineering things, frame rendering times are never equal and the eye don't notice differences of say...20ms... \$\endgroup\$
    – Quonux
    Commented Jul 1, 2013 at 13:45
  • \$\begingroup\$ To achieve a 60 frames per second update rate, 16.7ms frame updates are required. Film is standardized at approximately 41.7ms update rate (24 fps), but this is due to multiple factors, only one being perception. 20ms is a substantial amount. \$\endgroup\$
    – Evan
    Commented Jul 1, 2013 at 14:06
  • \$\begingroup\$ An note to author, you consider using a queue of RPC's or state changes (or your systems equal) that the client uses, as opposed to a singular state change. This is not uncommon, and can be seen in many games when a delayed update looks like a fast forward as opposed to a sudden and complete change of everything. \$\endgroup\$
    – Evan
    Commented Jul 1, 2013 at 14:10

1 Answer 1


I've written an article (http://www.gabrielgambetta.com/fpm3.html) which deals with this problem, I think in a slightly different way than what you're doing. May still be useful to you, though.


You must log in to answer this question.

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