On Wed, Feb 3, 2010 at 6:30 PM, R. Alan Monroe <amon...@columbus.rr.com>wrote:
> > 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. Details on here: http://gafferongames.com/game-physics/fix-your-timestep/ > 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 Try the http://gafferongames.com/game-physics/fix-your-timestep/ link. That can have the effect of in your loop That you have multiple physics * update()* calls per 1 *draw()* call. def game_update(): # ...draw() and physics_update() are called here example debug output of func call order: at: game_update at: physics_tick() at: physics_tick() at: physics_tick() at: draw() -- Jake
