Re: Question about timing

[Steve Baker <sjbaker1@airmail.net>]

Erik wrote:

> > c) is precise enough (I think) - but I am worried about portability and
> >    overrun. And, this is only for my process, correct?
> >
> 
> It is spec'd as measuring time since the beginning of the program. It's the one
> I suggest if you just want to normalize game time, so it doesn't run too fast
> to play on some machines and too slow to play on others. I'm not sure what you
> need precise time for, if you need a precise real world date/time, then this
> function may not be suitable. If you just need to know how long a frame took to
> render or something, this is probably the easiest and most portable way to do
> it.

No - (c) is useless for game physics timing because it measures the
amount of CPU time consumed by this program.

If the program is running at some speed by virtue of the speed of
the CPU, then 'clock()' could indeed allow you to correct for that,
but if some other program is running on the same computer and consuming
(say) half the CPU time - clock() will run at about half the speed of
'wall clock time' - hence slowing the game physics down.

Hence 'clock()' is inappropriate for game timing.

gettimeofday() is the nearest thing to a decent timer - but it carries
no precision guarantees.  Whilst it's pretty good under Linux on Intel
CPU's, there are no guarantees as to what precision you'd get under
(say) BSD UNIX, or under Linux on (say) a Mac or an Alpha.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk