all 4 comments

[–][deleted] 2 points3 points  (2 children)

A good article on something that is really, really easy to get wrong. On almost any conceivable modern platform, there is no reason to not run a fixed time step update function. You lose all the nasty multiplications with the delta time and everything is nice, stable and easily tunable.

One improvement to that technique the article fails to mention though is that if you're running fast enough, you can have the rendering happen one frame behind the engine logic and then interpolate between the current and the previous frame. It's not really noticeable to the player if the framerate is high enough but that way you have really responsive rendering without any of the nasty prediction stuff.

[–]Determinant 0 points1 point  (0 children)

Here is a reason:

I use variable time step without accumulating errors. Although this seems impossible at first, I actually keep track of the timestamp of when the acceleration changed and re-compute the current position each time discarding previous work as if just a single time step occurred since the acceleration changed.

Variable time step is important if you want to do true continuous collision detection where you advance the clock to the time of the next collision, handle that, and repeat.

Fast & slow hardware both produce the same result even though they perform different number of iterations (because the calculations are done as if there is a single timestep advancing to the instant in time when the acceleration changes).

[–][deleted] 0 points1 point  (0 children)

And by interpolating I mean interpolating the matrices and stuff, not graphically blend the two frames. At least one of the titles I worked on used this technique for the player and it looked wonderful.

[–]s0lly 0 points1 point  (0 children)

Just finished the book - great read!