Interesting Article about Timestepping

A friend of mine said that Delta Timing is not as smooth as this, and this article explains why. This article IS in C++ but I am trying to use the knowledge in BMAX, I'm just wondering what everyones thoughts are on this. I would like to make a TIMESTEP tutorial for everyone because this seems to be important. He says that this stuff is good and makes your games very smooth.

"The problem with Dela Timing"
The problem is this. Because we are using numerical integration the actual results depend on the size of the timestep. This is even true for advanced integrators like RK4. The larger the timestep the less accurate the results. So if you develop your simulation running at 60fps then at some point during your game the framerate drops to 10fps then all bets are off.

This may not seem like a big deal, but consider that in physics simulation, a small change in timestep can cause huge differences in behavior. If you have a series of really stiff spring constraints for shock absorbers in a car simulation then tiny changes in dt can actually make the simulation explode.

So ideally what we want is the best of both techniques. We want to choose a single dt so that every time the simulation runs it is stable and behaves exactly the way it was intended. At the same time we want the simulation to run at the same perceived speed irrespective of the display framerate. These two requirements seem completely at odds, and they are, unless we can decouple the physics and display framerates.


http://www.gaffer.org/articles/Timestep.html

Or you program you phyiscs engine to work properly with delta time. There are some very detailed papers on how to make that work and guess what, if your simulation drops to 10FPS everything still works.

The Photon Physics MOD by Cyanide, and modified by me demonstrates this very well.

My games use the retro 64 timing method. Not delata timeing, but a fixed speed logic loop. It might be the same as the Timestep method (I haven't read it yet :-))

Heh. I actually did my degree dissertation on this subject, never thought it would be useful. :)

What Gaffer's saying is essentially that you want to detach your physics update from your graphics update. Do your physics update with a fixed time step, but render it a little bit further on (without storing it) to catch up with your graphics update. That's a good idea I think.

If you really do want/need a variable timestep for whatever reason you can do some things to minimise the exploding effects. What you really don't want to do is have a drastic change in time step - you don't want to go from 60fps to 10fps to 60fps in a few frames because it will just make any physics simulation explode. A nice easy way to do this is to limit the change by 10% or so. So if you start with 60fps, then the next frame rate will be somewhere in the range of 54-66fps. That will certainly help stop your simulation exploding (for any integration method of second order or above, like RK2, for various reasons but Euler will still suffer badly) but it means that some slowdown/speedup will be noticable if there's a drastic change in framerate.

There is actually a way of determining how much of an error there is in a particular timestep, but I can't remember it offhand. I used a method that read this error and if it was too high then it decreased the timestep by 10% and tried again, if too low then it accepted the step but increased the timestep by 10% for the next time round. It made sure all errors were in check. Probably not very useful that is for realtime stuff like games though.

I use delta timing in everything and it serves me just great. Physics, movement, updates are all free from eachother, having their own time checker... great stuff. Ofcourse, having large gaps in time might break a rigid body or something like that, but for the type of games I make, delta timeing is just fine.

There's a bug in the document. When float currentTime = 0.0f; is declared it should actually be set to time() not 0, otherwise the first deltatime worked out will be huge i.e. newtime - 0 !!

OK, read it all, yeah bascially that's EXACTLY the same method I use when I say the Retro64 method. Except I haven't tried the interpolation trick. That's not really needed so much on a 2D arcade game though ... maybe.

Problem with the Frame Based method (Retro64) is that when the frame rate drops below the baseline (what you coded for) everything slows. I think they call it the "Nintendo too much on screen effect"

Yeah I had this too. Although the articles imples it won't happne but it does, I don't get it.