> The nice thing about limiting the framerate versus having calculations be
> done based on time passed is that it is much more consistent. With dt
> calculations you will often get huge jumps on slower computers and extra
> slow movement in cases on fast machines, just do to inaccuracies and error
> in the calculation. On a slower machine, no matter which timing method you
> use it will be unpleasant.
What kind of innacuracies, specifically?
For gravity, it's a huge difference. Create 1 planet and 1 asteroid.
Draw lines tracing it's movement.
With a fixed (physics) timestep: body orbits planet correct.
With dynamic physics timestep, the body escapes the gravity well.
> One method for having a smooth variable framerate, without the issues of
> variable time calculations, is to have a fixed time step. Each frame, you
> may process more than one timestep, if you need to in order to keep up. The
> timestep has a fixed amount of time it is supposed to similate, say, .02,
> which would be 60 times per second. If the user is able to run at 60 fps,
> they get very smooth animation, as only one step is occuring on each frame.
> If the user can only run at 30 fps, they will get two steps each frame, so
> it will be jerkier, but still accurate. If they can only run at 10 fps, you
> would set a limit on it (maybe the max is two timesteps in a frame), so
> things would be slower for them but maybe still playable.
> [code snipped]
Is anyone aware of any websites that describe this time/frame business
pictorially? I have read about it repeatedly and browsed a lot of
pseudocod over the years, but without a proper diagram it's not really
sinking in for a visual thinker like myself.
Alan