On Sat, May 24, 2008 at 7:59 AM, Francesco Martino <[EMAIL PROTECTED]> wrote:
> accurate results, the problem is that, if I am not wrong, any signal > could terminate the sleep sleep is an interruptible wait state so it can end early, but simple keyboard presses alone don't wake it. however it's fine if the sleep ends early (or even does nothing) with that code - the "while" loop with the sleep call in it works fine even if sleep ends early. In fact the "wait_for_time_from_start" routine expects sleep to be very inaccurate - it only tries to use it for most of large wait periods and always after sleep returns. It does a "busy wait" (i.e. polls time taking up the CPU) to take care of small wait periods and finish off what sleep didn't. is pygame.time.wait more accurate than time.sleep? > > pygame.time.wait is very similar to time.sleep, they are nearly the same, they use the same approach, get the same accuracy and usually get the same precision as well (even though sleep lets you specify finer than a millisecond, it's actual precision less than millisecond on most platforms) pygame.time.delay however does basically what the code I sent does, and has similar accuracy - the only real differences are the class I sent uses more precise timers (all pygame time stuff uses "ticks" or milliseconds internally, while the right python time functions for a platform get microsecond precision or better), and pygame.delay specifies the start of the delay from the time you call pygame.time.delay, while the AccurateWait class lets you start the delay, do some work, then finish the wait, making it easier to to do a wait where you wanted to do some work as part of that wait, or to put another way, to make it easier to control the rate at which your program does stuff (a lot like pygame.time's Clock.tick_busy_loop actually)
