Re: [pygame] time progression independent of game "ticks"

["Dave LeCompte (really)" <dave@xxxxxxxxxxxx>]

"Daniel Nixon" <dan.nixon@xxxxxxxxx> wrote:
> What advantage does calling pygame.time.wait() have over simply
> lowering the frame rate passed to .tick()?

I should really leave this one for folks who have been deeper into the SDL
C code, but my understanding is that (at least until recently) for small
frame times (frame rates above 30 fps? I don't recall), the
tick(framerate) call tries to be accurate - and it accomplishes this by
hogging the CPU.

The wait() approach, on the other hand, guarantees that your program
yields the CPU for a certain amount of time - you don't know when wait()
will return, but the clock.tick() function gives you the timing data that
you need, anyway. (And, don't worry - it's pretty close to the amount of
time you specified, but it might be a little off.)

The results of hogging all the CPU for your own process means that other
processes end up getting starved for CPU, which isn't a good idea on
multi-processing OSes (and who knows what the players are running in the
background).

All this ends up with a little bit of a counterintuitive practice: to get
smooth behavior, call wait(), even though it's unpredictable. It'll
average out and be more consistent than trying to manage time too
precisely.


-Dave LeCompte