I wanna use a timer for a game, but it's like after some research, I understood I should discard GetTickCount, cause its too low frequency.
So I'm left with timeGetTime and QueryPerformanceCounter.
timeGetTime according to what I've read, have a frequency of 1 millisecond on win 9x, but on winNT only a frequency of 5milliseconds.
Some sources suggested that on NT the frequency of timeGetTime can be set to 1 milliseconds per update by calling timeBeginPeriod with argument 1 before using timeGetTime, only that it will only succeed if THE HARDWARE SUPPORTS IT?!?, what's this supposed to mean?
Most people suggest using QueryPerformanceCounter, because it has below milliseconds frequency, but also suggest it is only available on some systems, hinting that these systems are like pentium and above.
Furthermore to increase confusion, it is said that certain pci-chipsets, will cause the PerformanceCounter to leap upwards on occasion, just to compensate some bug in the hardware. Grrrrr....

So I implemented a check for precense of performanceCounter, if PerformanceCOunter is not available use timeGetTime.
But if perf.counter is available and the app use it (2d - game) will there still be like there huge choppiness in the graphics on some chips, just because of that 'bug'?
Or will that buf not be like not really disturbing the gameplay??

If I'm using PerformanceCOunter I may not know if it will ruin gameplay, and if I use timeGetTime instead to be sure this pf-bug should not ruin,
I may use timeGetTime on an NT-system which maybe only can use a frequency of 5 milliseconds?!?
(which sucks because I update all movement depending on the time passed between frames)

Anyhow, I settled for first checking for queryPerfomanceCounter is possible,
if not use timeGetTime. Will this be ok?

I did check both versions on my winXP though, and I thought I saw more smoothness in the qpt-method, although it may be my imagination.

How would a Proffesional application handle this???????
(sorry for typing errors)

*increasing confusion and madness*
Posted on 2003-03-15 11:33:13 by david
I'm not sure about timeGetTime. I don't use it due to a higher resolution need.

As for QPC/QPF, in my experience it uses the PIT. I've read reports of it keying off RDTSC on some peoples boxes, but I've never seen it. ACPI yields higher QPF resolution. I discovered that fact while attempting to isolate the ACPI driver during problem resolution on hardware. The only time I had problems with the QPC function was using Win95 and certain MCI commands. I'm currently using NT 5.0 with no problems at all with QPF/QPC functions.

Not knowing your processor/OS target, I would suggest using all available timers, the two you mention and RDTSC. Donnerwolf submitted a killer CPU speed app that may help you through the curve of determining CPU frequency safely and accurately. Here's the thread for it:

http://www.asmcommunity.net/board/showthread.php?threadid=4424&highlight=cpuspeed
Posted on 2003-03-15 15:27:13 by alpha

I definitely always use the TSC and check it (from time to time) against QueryPerformanceCounter() to make sure that the CPU hasn't changed its speed (it may happen on some portable PC's). In that case I adjust my time bases, so that the TSC can again be used reliably.
With the security given above, I use the TSC a lot because it's precise and it's fast to read.

That was for polling based stuff and timing in general.. but if you need a timer to execute code at regular intervals (you shouldn't ideally, on a architecture like the PC), use a Multimedia Timer.
Posted on 2003-03-15 15:27:20 by Maverick
Scronty was nice enough to translate m$'s dx timer code.
Take a look in dxutil.inc for the code.
It's just what they describe, it tries the HP timer first, then falls back onto the regular one. Its really a nice handful of functions.
Posted on 2003-03-17 08:42:50 by Homer
THANKS ALL! :)

Trying to find dxutils.inc by search on the forum, but dont get a single hit, checked my masm32/include folder, and checked Mr Scronty's
site...didnt find it. Did I make some mistake?

I'm making alright with my current timing routines for myself, and another friend who tested. Just test for highPerformanceCounter and use if available else timeGetTime. But I'm still kinda worried how to fix that
eventual bug of the high frequency timer, which could jump ahead a second or more, which I heard a rumour of.

I cant figure out how to fix that if it would happen, maybe I could do both highPerformanceCounter and timeGetTime simultanous,
checking current HPC-value against the last one, and if above a second or something, fall back on timeGetTime, but how can I get back to HPC? Will the HPC decrease back to normal after the bug or just go on the same, increased by a second??!?
Especially without a buggy system (mine seems not to be suffering from this) it's very hard to find out, or try ideas.
( if you are me that is :grin: I dont get it )

If dxutils.inc does a fix to this, pls let me know where I can find it ( hi Scronty! :tongue: )
Posted on 2003-03-17 20:45:27 by david
Afternoon, david.

My site is *still* under heavy reconstruction, and so there's no link to the win32asm DX8.1 stuff as of yet.

Go to http://www.scrontsoft.com/win32asmdefault.asp and click on the DX8.1 Examples pagelink.
Scroll down to the first DolphinVS.zip you find (it's 187kb) and click on the zip to download.

dxutil.asm is inside that zip.

Cheers,
Scronty
Posted on 2003-03-17 23:58:05 by Scronty
Thanks!

Wow, the dolphin is so pretty! :)
Posted on 2003-03-19 08:18:44 by david
Just returned recently from a place called Monkey Mia where dolphins beach themsleves at your feet - at three times of the day, like clockwork.
Scronty's dolphin is actually far less mechanical than the real thing :tongue:
Posted on 2003-03-20 23:09:54 by Homer