RE: [GD-Windows] More timer fun!

[Tom F. <to...@mu...>]

Sounds like one Jon should definately write, seeing as he's got something
robust working. Go on Jon, do it. You know you want to.

Presumably for a once-per-cycle timer test (which is all you usually need
for games) you could use QPC, but spot the quantum leaps (forwards and
backwards) by watching timeGetTime() deltas.

In retrospect, timeGetTime() slippage is almost certainly what is killing
many networked games of StarTopia - they start out fine but after half an
hour or so of play they get too far out of sync and die. The system will
cope with a certain amount of lagginess, but gives up at about five seconds,
assuming that your network connection is stuffed. And of course all our
testing in the office was on mainly one or two very similar models of Dell,
so we never saw this problem, even after many hours. Curse those hardware
designers!


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 30 August 2002 15:53
> To: gam...@li...
> Subject: Re: [GD-Windows] More timer fun!
> 
> 
> Somebody should write a definitive Gem about this (say in GPG 
> 4 ?). Or maybe
> someone already has and I don't know about it ? Is there a 
> place explaining
> the issues and, hopefully, giving canonical source code to 
> solve them once
> and for all ?
> 
> Pierre
> 
> ----- Original Message -----
> From: Jon Watte <hp...@mi...>
> To: <bri...@py...>; 
> <gam...@li...>
> Sent: Friday, August 30, 2002 6:51 AM
> Subject: RE: [GD-Windows] More timer fun!
> 
> 
> >
> > timGetTime() / GetTickCount() only return 32 bit values, AFAIK.
> >
> > There are some problems with keeping time on PC hardware. 
> timeGetTime()
> > will lag behind wallclock time when there is lots of bus traffic (==
> > graphics-heavy application running). QueryPerformanceCounter() will
> > somtimes jump ahead by 1.3 or 4.1 seconds when there is lots of bus
> > traffic, in a quantum leap. RDTSC ticks once per cycle, but mobile
> > CPUs will adjust their CPU frequency quite often, so you can't get a
> > good bead on that, either.
> >
> > Also, QPC and TGT/GTC each take a bus transaction to 
> execute, and thus
> > run in 1-2 microseconds, which is an eternity if you need 
> to call them
> > more than once or twice per frame rendered.
> >
> > I ended up with an unholy concoction of all three methods, 
> which ends
> > up getting good overall relation to wallclock time, cheap calls, but
> > some local mis-match where my clock will lag behind 
> wall-clock "locally"
> > but get adjusted "globally" when the CPU goes into powersave mode.
> >
> > Yuck.
> >
> > Cheers,
> >
> > / h+
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>