"Daniel Nixon" <[EMAIL PROTECTED]> wrote: > Thanks Ian, Dave. Passing down the milliseconds sounds like the way to > go. Thanks for the great advice. :)
Actually, let me refine my suggestion. Back a month or more ago, I kicked off the whole "a CPU is not a saw" thread with a discussion very similar to this, and what I would suggest based on the opinions voiced at that time would be to make sure that you leave a few cycles each frame for the OS. If you're reasonably confident that you can pick a frame rate that the slowest machines can keep up with, and then some, all you'd have to do is pass in the argument to the tick() call: TARGET_FRAME_RATE=25.0 while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) If you want to be extra sure to give up a few cycles to the OS, you can add in an explicit delay: TARGET_FRAME_RATE=25.0 WAIT_TIME=5 # number of milliseconds per frame to yield to other processes while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) pygame.time.wait(WAIT_TIME) tune these numbers to where you feel comfortable with them. I feel bad plugging my game over and over again, but if you look at the 0.9 version of the code, it wasn't yielding any time to the OS, and sometimes things felt a little uneven. 0.91 and 0.92 are more aggressive about using more CPU-efficient approaches, and I decided to use a 60fps target. The result was much smoother performance. 0.9: http://www.pygame.org/projects/23/415/?release_id=698 0.92: http://www.pygame.org/projects/23/415/?release_id=767 -Dave LeCompte