RE: [GD-Windows] More timer fun!

[Tom H. <to...@3d...>]

At 10:49 AM 9/2/2002, Tom Forsyth wrote:
>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.

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). Basically, you use QPC and watch out for large jumps, or 
negative deltas, and if they occur, you validate the results with 
timeGetTime(). In the case of a bogus result, you use the timeGetTime() 
results instead. There's reasons for not using timeGetTime() for 
everything, though what they are escapes me at the moment.

The "bad" thing is that the calls themselves can take a decent amount of 
time, but reliable timing is much more important than ultra fast timing. 
And, realistically, 1 to 4 microseconds per-frame for games is a perfectly 
reasonable amount of time to spend on getting timing information. In 
practice, I've never found a reason to have a lot of different timer calls 
per frame, though I guess others may. It just seems like it would make a 
great many things unnecessarily difficult.

Tom