RE: [GD-Windows] More timer fun!

[Aaron B. <aar...@po...>]

> 
> As I understand it, what you describe is the MS preferred way 
> to deal with 
> performance/accuracy critical timing (I seem to recall there 
> being an MSDN 
> article or tech note on the subject, but a quick search didn't find 
> anything). 

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&ID=KB;EN-US;
Q274323

> results instead. There's reasons for not using timeGetTime() for 
> everything, though what they are escapes me at the moment.

It returns a value in millisec, but I've seen it return the same value for
20ms or longer - i.e. it was only "ticking" about 50 times a second. More
recently I've seen it accurate to 5 or 10ms.

Actually, from the docs:

Windows NT/2000: The default precision of the timeGetTime function can be
five milliseconds or more, depending on the machine. You can use the
timeBeginPeriod and timeEndPeriod functions to increase the precision of
timeGetTime. If you do so, the minimum difference between successive values
returned by timeGetTime can be as large as the minimum period value set
using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and
QueryPerformanceFrequency functions to measure short time intervals at a
high resolution, 

Windows 95: The default precision of the timeGetTime function is 1
millisecond. In other words, the timeGetTime function can return successive
values that differ by just 1 millisecond. This is true no matter what calls
have been made to the timeBeginPeriod and timeEndPeriod functions. 


You could simply average the returned value from timeGetTime() over the last
N frames, but you might get visible speed changes if the frame rate suddenly
changes...

Aaron.