Some games do indeed extrapolate.
An advantage of extrapolation is that you can do it with just the single most recent state and a rate of change (like velocity, angular velocity, etc.) rather than two complete states. So it is simpler to implement and compute.
The main disadvantage of extrapolation is that it's a prediction about the future, and like most such predictions, it can be wrong.
Say the player has just started changing directions or slowing to a stop, but their current velocity is still pointing in their old travel direction. With extrapolation, they'll see themselves overshoot, then snap back to a different course when the next simulation step factors in the change in velocity, resulting in a jerky appearance that can look a bit like a bad framerate or network lag (even when both those systems are running smoothly).
Since you're generally not running a full simulation step for the extrapolated state, systems like collision detection don't run on these in-between frames. So your extrapolated velocity might take you partway into a wall or floor, or over-extend a physics joint beyond its correct range of motion, before the next simulation step correctly resolves this situation.
These artifacts usually aren't game-breaking, but they can be quite unsightly.
In contrast, by interpolating two previous simulation steps, we have a strong guarantee that we'll have continuous motion: the end of one interpolated interval is guaranteed to match the start of the next one, unlike with extrapolation. And because we're blending between two known-good states, the chances we do something ridiculous in-between like pass through a solid object or rip apart a physics joint are greatly reduced.
The cost is that the state we're displaying is technically a tiny fraction of a second older.
But "older than what?" is the question. The player's perception of what constitutes "now" in the game is informed by the visible, audible, and tactile feedback we present. If the numbers inside the computer memory representing the most recent state we simulated are technically a tiny fraction of a second ahead of the displayed state, it's difficult for the player to observe that directly.
The one place it can be perceived is in input latency. The player knows "I pressed this button now" so if it takes a few frames for visible/audible/tactile reactions to that button press, that can reveal the time mismatch.
Fortunately, as I explain in more depth in this answer, this input latency is often much less than you might expect, and by eagerly presenting fresh input feedback immediately, even on an interpolated frame, we can shrink the perceived latency down to the resolution of our display framerate.
So we can make a game that feels just as responsive as one that's extrapolating, but without the juddery errors of mis-prediction, and that's why we usually prefer to interpolate.
while(accumulator >=0)
so that the frame timet+accumulator
is between integration timest-dt
with statepreviousState
andt
with statecurrentState
. Upon external input you will need to re-compute the step or restart the integration with the changed parameters. \$\endgroup\$t+acc
is between the pastt-dt
and the futuret
. There might not be truth to the future state as events may still happen, but the interpolation at the present time is the truth within the given accuracy. I do not develop game engines, so I'm not sure if there is not a deeply philosophical counter argument. \$\endgroup\$dt
to the frame rate. If there are several frames per integration step, likely only for higher order integration methods, interpolation is really better than extrapolation, there might be noticeable jumps from one extrapolation arc to the next. In the converse direction, several integration steps per frame, which happens for lower order methods, there will be not much difference between the approaches. \$\endgroup\$