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