with respect to the following article:

http://gafferongames.com/game-physics/fix-your-timestep/

at the end, where he's interpolating values based on fractions of a time step left over,

am i to understand it that for example, the physics simulation is on time step 4.5, and he uses that .5 left over to interpolate between time steps 3 and 4, to come up with values for timestep 3.5, then draws the interpolated state of the simulation at time step 3.5 when the simulation is _actually_ at timestep 4.5? IE drawing based on an estimated past state, not the true current state of the simulation? And always draws ~1 frame behind whats actually going on?

i take it that the physics engine and render engine running slightly out of phase temporally (~1 frame) has no major impact on gameplay?

and without interpolation, you get the temporal aliasing of the occasional 2 steps per frame when the accumulator rolls over?

and interpolation is really only required for deterministic games ?

am i to understand it that for example, the physics simulation is on time step 4.5, and he uses that .5 left over to interpolate between time steps 3 and 4, to come up with values for timestep 3.5, then draws the interpolated state of the simulation at time step 3.5 when the simulation is _actually_ at timestep 4.5?

The simulation is never at 4.5. It's either at 3, or 4.
The graphics however can use interpolation to estimate how it should look at 3.5
The physics is in time step 4, the graphics is at 3.5, and he takes steps 3 & 4 to interpolate and show how 3.5 looks, even though the simulation is actually at timestep 4

IE drawing based on an estimated past state, not the true current state of the simulation? And always draws ~1 frame behind whats actually going on?

Yes and yes.

i take it that the physics engine and render engine running slightly out of phase temporally (~1 frame) has no major impact on gameplay?

There's a lot of research and debate over that (particularly for action and fighting games). It's not set in stone. Note however that this is relative: even if you don't interpolate, if the physics processing is much faster than the graphics, it will always be one frame behind what the physics is, because the physics needs to be calculated before it can be displayed, and while it is being displayed, the physics from the next step are already being calculated and almost done.

Games with very high framerate in their physics don't really need to interpolate, but the higher the framerate, the lower the latency (being one frame behind) is noticed: because being one frame behind means being less time apart the higher the framerate (at 60fps, we're 16.6ms behind, at 30fps we're 33.33ms behind); so games that are simulated at high Hz don't care anyway

and without interpolation, you get the temporal aliasing of the occasional 2 steps per frame when the accumulator rolls over?

You forgot the most important reason, and that is choppy framerate. Many engines simulate at 30hz or 25hz but display at any framerate. Thus if your gpu is fast enough to display at full 60fps, you really don't want it to look at 30fps (or even 25fps!).
With interpolation, it looks smooth (assuming your gpu can handle the load).

and interpolation is really only required for deterministic games ?

Interpolation is never required, it's an optional, very handy feature.
Second, interpolation is used in games with fixed timesteps (as opposed to variable timesteps, where it is pointless to interpolate).
Fixed timesteps are necessary to have deterministic games, but not all games with fixed timestep are deterministic. Interpolation can be used in both cases.
And any game with variable timestep can not be deterministic.

Notice that it's OK to compute the state at time 5 now, because it can only be affected by inputs available at time 4, which we have.

tricky! ; )

so interpolating between current and next isn't a problem, as next is based on current's input. this does assume a certain order to input, render, and update though, doesn't it?

in the end, they're endless loops, so the particular order doesn't always matter, or two orders may be functionally similar, but not both start at the beginning of the game loop.

render, input , update is simply an out of phase version of input.update,render, that starts with render instead of input on the first iteration. once the loop is running, there's no real difference. only perhaps as far as which "step", "turn" or "frame number" you say something is on.

i use the render, input, update ordering. so there, one might say i render step 4, then get input for and compute step 5. on the next game loop iteration, i draw step 5, and get input for and compute step 6.

from this description you can probably tell i take a very different approach to the main game loop as far as coupling / decoupling the input, update, and render parts of the code. thus my interest in the topic.

You forgot the most important reason, and that is choppy framerate.

So its really all about smooth high speed animation then? run update() at 30 fps, and let render() scream at full throttle, and just interpolate between frames, like animation tweening, eh?

You forgot the most important reason, and that is choppy framerate.

So its really all about smooth high speed animation then? run update() at 30 fps, and let render() scream at full throttle, and just interpolate between frames, like animation tweening, eh?

yes, interpolation is nice...

note that interpolation (and also extrapolation) may also be relevant in network games, partly as the server may send out delta-frames at a relatively slow rate, and also ping-times may be potentially significant. so, it may be necessary to extrapolate ("guess") where things are at the current time, rather than exactly where the server said they were, ...

note that interpolation (and also extrapolation) may also be relevant in network games, partly as the server may send out delta-frames at a relatively slow rate, and also ping-times may be potentially significant. so, it may be necessary to extrapolate ("guess") where things are at the current time, rather than exactly where the server said they were, ...

as a hard core flight sim fan, the mere mention of simulation inaccuracies like lag and prediction makes my skin crawl! <g>. i want to simulate, not play a mere game.

however i do realize they are a necessary evil required for networked titles.

i've only added multiplayer to one of my games ever. it was a flight sim, and ran in lockstep. the protocall was proprietary, and so robust that you could unplug the phone line and not lose sync. however it was not 100% bulletproof. i don't think any protocall can be. you can only ACK ,ACK's so many times. eventually you have to take it on faith that the last "i got your ack" goes through

.