QueryPerformanceCounter issue
category: general [glöplog]
recently i notice that my 1k intro doesnt have the right speed, i adjusted the values and compile it. it was ok.
then i used to watch some demo on pouet and after intro was not at good speed anymore (2x or 3x too much speedy).
i have another version of intro using timegettime and here not problem at all with speed
actually t variable is updated that way :
Code:
oldtime = previous QueryPerformanceCounter() call
currenttime = QueryPerformanceCounter()
frequency = QueryPerformanceFrequency()
delta = currenttime - oldtime
t = t + delta/ frequency
i suspect QueryPerformanceCounter or QueryPerformanceTimer to dont give exactly same result after some demo or program use it.
it change precision, the way it this updated or something like this
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.mindcontrol.org/~hplus/pc-timers.html
etc.
Basically, it's broken, and may very well give strange results on >1 core machines. Use timeGetTime if you can. AMD and Intel has created a few patches to fix some of the issues with it, they should be on their web sites somewhere.
http://www.mindcontrol.org/~hplus/pc-timers.html
etc.
Basically, it's broken, and may very well give strange results on >1 core machines. Use timeGetTime if you can. AMD and Intel has created a few patches to fix some of the issues with it, they should be on their web sites somewhere.
hell yeah it's a complete mess :(
thx !
Dont know it was so bad. i'll try TimeGetTime(), the only bad thing is i need one more import (winmm.dll) in a size restricted environement (1k).
Maybe i should take a look at GetTickCount() which require no import at all, but seems to be not so precise
(dont know if someone will notice, the timer will control a 2d fullscreen shader...)
Dont know it was so bad. i'll try TimeGetTime(), the only bad thing is i need one more import (winmm.dll) in a size restricted environement (1k).
Maybe i should take a look at GetTickCount() which require no import at all, but seems to be not so precise
(dont know if someone will notice, the timer will control a 2d fullscreen shader...)
Guess what... I just tested a game of mine with timeGetTime and QueryPerformanceCounter. While on my (overclocked) Core2Duo E6600@3GHz and an ATI Radeon HD 4650 i had constant 285 FPS (according to fraps), the animation was so jerky, i'd say it was 3-4 "visible" FPS, as if the timer resolution of timeGetTime was ~200ms. Other computers (one laptop and a normal non-overclocked PC) ran the game fine.
I changed it to QueryPerformanceCounter, and finally it was also smooth on my PC.
I changed it to QueryPerformanceCounter, and finally it was also smooth on my PC.
you can overcome most of the problems with the performance counter.
make sure your calls to the pc is done from the same cpu. you can set the affinity on your threed to make sure this is true, and secondly always poll the frequency since it can change (especially on laptops).
make sure your calls to the pc is done from the same cpu. you can set the affinity on your threed to make sure this is true, and secondly always poll the frequency since it can change (especially on laptops).
Hm, querying the frequency each frame does indeed stabilize the time, thanks for the hint. I can hereby recommend this for everyone.
QueryPerformanceFrequency is always wrong on my eeepc 1000H when called while the cpu is in "power-saving" and "performance" mode, it always returns the frequency from the cpu's "normal mode".
