> 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? > 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
