"Daniel Nixon" <[EMAIL PROTECTED]> 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