lutger.blijdestijn at gmail.com
Wed Oct 25 17:21:15 PDT 2006
> Thanks for the reply.
>>> It's probably because of the sleep function, this can be off by about 10
>>> to 16 ms usually on windows, iirc.
> I think so too, except that the usleep is never off by more than 2ms here ;)
> My program will only be run on one computer, which makes it alot easier, but
> I already decided to let my AD card determine the rate.
>>> Beware that sometimes QueryPerformanceCounter, which
>>> HighPerformanceCounter uses, can behave erratically on dualcore systems
>>> and systems with variabele clock speeds (Intel's Speed Step, AMD's cool
>>> 'n quiet).
> I've been reading through the msdn:
> As I read it QPC takes care of multicore etc. (I only care about winxp
> directx9 :)
> Only if QPC determines that the RDTSC is a stable counter will it use that
> Otherwise it searches for a better source (mainboard counter chips etc).
> What I do miss is the QueryPerformanceFrequency to check the granularity or
> did I just miss it somewhere?
Unfortunatly QPC does not always play nice with multicore as said in
that article: "While the QueryPerformanceCounter /
QueryPerformanceFrequency API is intended to be multiprocessor aware,
bugs in the BIOS or motherboard drivers may result in these routines
returning different values as the thread moves from one processor to
another. We recommend that all game timing be computed on a single
thread, and that thread is set to stay running on a single processor
through the SetThreadAffinityMask Windows API."
And then there is variable clock speed, buggy hardware. I sometimes have
leaps a few ms forward in time, seems to be a because of a defect in
the southbridge. Timing bugs are not fun...
QueryPerformanceFrequency is only for checking counts per second, but
granularity of QPC should be good, it just can have some overhead per call.
More information about the Digitalmars-d-learn