gamedevlists-windows

[GD-Windows] More timer fun!

[brian h. <bri...@py...>]

Well, in the process of trying to figure out why on a very few systems 
(maybe less than 1%) my timing code was messed up, I stumbled across 
this tid bit at the Pest Patrol Web site:

"A Range Check Error can occur on DELL computers running Windows ME 
with software using the Windows function GetTickCount. In such systems, 
this function is not returning the elapsed time since system power on, 
and the value returned can be enormous, causing a range check error. 
Dell's Range Check Error affects timeGetTime as well as GetTickCount. A 
third timing function, therefore, has been used in PestPatrol, 
PestPatrolCL, and PPUpdater."

Well, sure enough, the two users I know that were having this problem 
have Dell Dimension L's with Windows ME.  I'm not sure what the 
specifics of this problem are (I'm using 64-bit ints already), but I do 
some more range checking now and hopefully this problem goes away.

-Hook

RE: [GD-Windows] More timer fun!

[Jon W. <hp...@mi...>]

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+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> brian hook
> Sent: Thursday, August 29, 2002 9:40 PM
> To: gam...@li...
> Subject: [GD-Windows] More timer fun!
> 
> 
> Well, in the process of trying to figure out why on a very few systems 
> (maybe less than 1%) my timing code was messed up, I stumbled across 
> this tid bit at the Pest Patrol Web site:
> 
> "A Range Check Error can occur on DELL computers running Windows ME 
> with software using the Windows function GetTickCount. In such systems, 
> this function is not returning the elapsed time since system power on, 
> and the value returned can be enormous, causing a range check error. 
> Dell's Range Check Error affects timeGetTime as well as GetTickCount. A 
> third timing function, therefore, has been used in PestPatrol, 
> PestPatrolCL, and PPUpdater."
> 
> Well, sure enough, the two users I know that were having this problem 
> have Dell Dimension L's with Windows ME.  I'm not sure what the 
> specifics of this problem are (I'm using 64-bit ints already), but I do 
> some more range checking now and hopefully this problem goes away.
> 
> -Hook
> 
> 
> 
> -------------------------------------------------------
> 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
> 

Re: [GD-Windows] More timer fun!

[Pierre T. <p.t...@wa...>]

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+