[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] frame independant movement



On Feb 3, 2010, at 4:30 PM, R. Alan Monroe 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?

Typical incremental algorithms used in games to simulate "physics" (or even just basic non-linear movement) give different answers over time with different time step intervals. Simple algorithms, such as Euler's method in particular, are especially bad in this regard. This is true even if the time step does not vary over time, but can become especially acute if it does. If for example, time steps have been coming at a steady 30/sec and all of a sudden a few steps are at a rate more like 5/sec, things can not only become inaccurate, but also unstable if you aren't careful.

Think about it this way, if you have many bodies in motion in a game, the more they move each frame, the harder it is for you to accurately simulate how they interact. When things move too far each step, things can penetrate or pass through things, generate ridiculously large collision response forces or start resonating and shatter into a million pieces. 

Also at long time step intervals any code that polls the player's controls or AI code gets called much less frequently, changing the whole behavior of the game in undesirable ways.

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

It's tough to generalize this visually, but here's an example of how Euler's method diverges from an exact simulation over time:

http://www.boomer.org/c/p3/c10/c1002.html

-Casey