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

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

"Daniel Nixon" <dan.nixon@xxxxxxxxx> 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