[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Bouncing ball - separating the physics from the frame rate



Patrick Mullen wrote:

> The only downside to this
> method, is if the framerate goes down, the physics will slow down
> along with it - but this may be preferable to jerkiness anyway.

Right. You don't want the physics to run too far ahead of
what's displayed on the screen. If rendering gets slowed
down for any reason, I find it's better to just let the
physics get slowed down as well. Otherwise the game starts
taking big jumps and becomes difficult to play.

The way I'm doing this in my games at the moment is to
set up a timer which sends events at regular intervals,
let's call it dt. Whenever one of these events occurs,
I set a physics_update_needed flag. Then my main loop
does something like

   Get all the events that have occurred since last
     time round the loop
   Process all of these events
   If physics_update_needed is set:
     Advance physics by dt
     Clear physics_update_needed
   Render

The result of this is that as long as an update/render
cycle can be done in less than dt, everything proceeds
smoothly with frames dt apart. If not, the frame rate
and game speed slow down together to whatever can be
supported.

I prefer to use timer events rather than clock.tick(),
because I don't like the idea of busy waiting. It's
a really bad thing to do on a multitasking system.

--
Greg