RE: [Algorithms] Game loop timings

[Dave 'Z. K. <Zo...@Re...>]

From: Tom Forsyth [mailto:tom...@ee...] 
>Fixed-time-increment _rendering_ is hard for the reasons Chuck mentioned.
>But having your internal game state update at a fixed increment, or
multiples
>thereof, is not. A lot of games do it, and it removes a lot of problem with

>reproducibility of results. Having your game change behaviour between debug
and release, 
>or just by maving the camera, is not a good thing.

The best example of this I can think of is the Quake engine games.  If you
had a low framerate, you could jump higher.  The variable update
quantization would cause rounding errors in the player movement code and
when the error was compounded over multiple frames, you end up with a higher
jump.  This allowed people to essentially cheat in multiplayer since they
could just limit their framerate and jump on a box other people couldn't.

Every game I've worked on since Quake has used a fixed update rate,
regardless of framerate.  This isn't too bad on consoles, since you're
locked at 60FPS for an NTSC signal anyway.  But PC space has had some
resistance, for example Doom3 is locked at a 60Hz update rate.  People
buying the latest GeForces don't see 200FPS in the corner and get confused.

I'm completely sold on a fixed update rate.  It just makes debugging and
development easier.  The only fun part was actually changing it to 50Hz for
our PAL version.  That actually exposed bugs since the player was moving a
little further each frame.

--Zoid
zo...@re...