RE: [Algorithms] Game loop timings

[igrok <ig...@bl...>]

Can you explain how I take the rendering time and work this in to the
AI update time?

Currently, I have updates like this for the AI. (all multiples of 20fps)
0.05 seconds
0.05
0.05
0.10
0.05
0.05
etc.

The 0.10 slips in because gradually the applied timer gets our of sync
with the real amount of time passed and that must be made up at some
point.
The thing is, it is very noticable as a character on screen will
suddenly
jump a further distance than normal. It certainly doesn't look as smooth
as when I've just been using basic 'time between frames' approach to
update objects.

Maybe this is what you are suggesting:
Game update takes  0.0010 seconds
Render frame takes 0.0015    (total=0.0025)
Render frame takes 0.0015    (total=0.0040)
Sleep for 0.0010 (because no time for next render frame before 0.05)
Game update etc.

So this would waste a certain amount of CPU time, but would only cause
a slip if a render frame took



-----Original Message-----
From: gda...@li...
[mailto:gda...@li...] On Behalf Of Tom
Forsyth
Sent: 31 March 2005 18:38
To: gda...@li...
Subject: RE: [Algorithms] Game loop timings

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.

There's a huge thread about this from a while back (a year or so?). It's
one
of those semi-religious arguments, but I've done games with fixed
increments
and variable increments. Despite being a lot simpler, the ones with
variable
increments had tons of annoying bugs that "went away" in one build or
the
other, recording demos was hard, you'd get bugs that could only be
reproduced on some machines, etc. Nightmare.

Not sure what it's got to do with the V-blank timer. Just use any old
timer.
All you want to know is how long your rendering took.


TomF.


> From: Chuck Walbourn
> 
> Fixed-increment timing code is problematic on the PC now matter how
> clever you are about it.  Since the performance characteristics of the
> system will vary widely from system-to-system, and even on the same
> system from driver-to-driver or due to component upgrades, you are
> inherently dealing with variable timing.  Fixed-increment timing code
> also breaks when you are doing debug vs. release builds, profiling, or
> have to cope with variability introduced by multi-threading or
> background processes that the user wants/needs to have active while
> playing your game.
> 
> Now, you can certainly set up your AI/physics to run a lower rate than
> your rendering rate.  You can probably get close to constant 
> increments
> if your resolution is low-enough via multi-media timers, but you will
> have to be stable enough to deal with the occasional glitch.
> 
> -Chuck Walbourn
> SDE, Windows Gaming & Graphics





-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88