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

Re: [pygame] frame independant movement



The way Patrick describes is *by far* the most common way the main loop is done in professional games. As he said, it provides consistent game behavior but allows the actual frame rate to vary based on what the platform can actually provide. The system actually works very very well, as long as drawing takes longer than updating (which it still usually does, partially cause of vsync to the screens refresh rate). However, if updating takes significantly longer than drawing, then doing n updates for each draw ends up making a less playable game versus just slowing down game play and having one update per draw (but if that's your case, the gameplay suffers no matter what your main loop does, so maybe it doesn't matter)

...and .02 is 50 fps, not 60 :)  GAMESPEED = 1/60.0 would be a better way to do that.

.. and for max, I personally think 4 works really well, cause 15fps with a 60 cycle per second simulation is usually quite playable, but if your fps drops below 15, it's usually more playable to also slow the game down.


On Wed, Feb 3, 2010 at 11:59 AM, Patrick Mullen <saluk64007@xxxxxxxxx> wrote:
One method for having a smooth variable framerate, without the issues of variable time calculations, is to have a fixed time step. Each frame, you may process more than one timestep, if you need to in order to keep up. The timestep has a fixed amount of time it is supposed to similate, say, .02, which would be 60 times per second. If the user is able to run at 60 fps, they get very smooth animation, as only one step is occuring on each frame. If the user can only run at 30 fps, they will get two steps each frame, so it will be jerkier, but still accurate. If they can only run at 10 fps, you would set a limit on it (maybe the max is two timesteps in a frame), so things would be slower for them but maybe still playable.

def dostuff(dt):
   man.x += speed*dt

GAMESPEED = .02

while 1:
   dt = clock.tick()
   max=2
   while dt>0 and max:
      dt -= GAMESPEED
      max -= 1
      dostuff(GAMESPEED)

There might be other problems with this, I've never done it this way, only seen it referred to. I know in some engines, like doom3, the physics of everything, game logic etc, happens at a fixed 30hz rate; whereas animation of the scene is much smoother.

I am usually lazy and just do clock.tick(30) lol.