Re: [pygame] frame independant movement

[Patrick Mullen <saluk64007@xxxxxxxxx>]

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. 

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.

def dostuff(dt):
ÂÂ man.x += speed*dt

GAMESPEED = .02

while 1:
ÂÂ dt = clock.tick()
ÂÂ max=2
ÂÂ while dt>0 and max:
ÂÂÂÂÂ dt -= GAMESPEED
ÂÂÂÂÂ max -= 1
ÂÂÂÂÂ dostuff(GAMESPEED)

There might be other problems with this, I've never done it this way, only seen it referred to. I know in some engines, like doom3, the physics of everything, game logic etc, happens at a fixed 30hz rate; whereas animation of the scene is much smoother. 

I am usually lazy and just do clock.tick(30) lol.

Timing gets even more interesting when you do multiplayer, then you are dealing with different time rates for each player. Fun stuff :)

On Wed, Feb 3, 2010 at 3:38 AM, Renà Dudfield <renesd@xxxxxxxxx> wrote:

On Wed, Feb 3, 2010 at 7:06 PM, DR0ID <dr0id@xxxxxxxxxx> wrote:
> On 03.02.2010 11:25, inigo delgado wrote:
>>
>> "Another thing you can do is just use Clock to limit the FPS to 60 or
>> something, but then your game will run slower if you're not getting 60 fps."
>>
>> Well, true, but you MUST determine the framerate that Âyou want for your
>> game, otherway you will get a 60 FPS in your PC, 70 in another and 120 in
>> another one that is much more faster/newer than yours and in witch your game
>> will turn unusable at this framerate....
>>
>> I do this:
>>
>> while(true): #principal loop
>> Â Â# get current time
>> Â Ât = time.time()
>> Â Â....
>> Â ÂdoAll()
>> Â Â....
>> Â Â#At the end i get the time needed to do the calculatons & flip
>> Â ÂT = t - time.time()
>> Â Âdelta = T - 1/desiredFrameRate
>> Â Âif (delta > 0): # if the cycle has been done too fast
>> Â Â Â Âtime.wait(delta)
>> Â Â####This way you have your desired framerate or the maximum possible.
>> Additionally you can do this:
>> Â Âelse:
>> Â Â Â ÂGLOBAL_T = GLOBAL_STANDAR_T - delta # delta is <= 0, - and - is +
>>
>> Being GLOBAL_T the t that you use for your position calculations and
>> global_standar_t the value of global_t if delta is 0.
>
> Hi
>
> You will get different framerates only if you don't limit the fps. Using
> http://www.pygame.org/docs/ref/time.html#Clock.tick you will have always the
> specified framerate except if the cpu can not keep up (then it will run
> slower), but on faster machines tick will wait, similar to what you do (tick
> might be more accurate).
>
> ~DR0ID
>

Just another note... use Clock.tick_busy_loop if you don't mind
burning a bit of cpu to get far more accurate sleeping. ÂThe OS sleep
is often a bit random - and not really meant for accurate sleeping.


cu,