RE: [Algorithms] Game loop timings

[Tom F. <tom...@ee...>]

> People buying the latest GeForces don't see 200FPS in the corner and =
get
confused.

They should still see huge framerates if you interpolate. In fact, if =
your
rendering rate is anywhere near your update rate (i.e. within a factor =
of
about five), you really need interpolation, or you're going to get bad
aliasing between rendering and update, e.g. first frame gets two =
updates,
next frame gets three, next gets two, etc - stuff judders horribly when =
this
happens.

So they should still see 200fps (well, not that you can see 200fps on a
monitor running at 85Hz, but the graphics card is rendering the scenes =
that
fast).

The most extreme examples of this are RTS games, which frequently have
updates far lower than people expect. Because as long as you =
interpolate,
people just can't tell. StarTopia had 6 updates per second for example, =
and
at one stage (to run on min-spec machines) we almost dropped it to 3.

TomF.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...] On Behalf Of Dave
'Zoid' Kirsch
Sent: 01 April 2005 15:16
To: gda...@li...
Subject: RE: [Algorithms] Game loop timings


From: Tom Forsyth [mailto:tom...@ee...]=20
>Fixed-time-increment _rendering_ is hard for the reasons Chuck =
mentioned.=20
>But having your internal game state update at a fixed increment, or
multiples=20
>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,=20
>or just by maving the camera, is not a good thing.=20
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=20
zo...@re...=20