Back to General and Gameplay Programming

QueryPerformanceCounter Win32 timer slower than normal

NULL NULL · 2013-11-14T10:16:57

Hello, windows high res timer QueryPerformanceCounter always seems to act quirky whenever I use it. I remember to set the thread affinity to cpu 0, and the timer runs perfectly at 1 second per frame, but I want it to run at 60 fps, I tried dividing the timer frequency by 60, but it still runs too slow, and even dividing it by 10000 keeps it slower than 60 fps. I do not know what I am doing wrong. Here is my code: while(destroyed != 2) { QueryPerformanceCounter(&gameTimer->currentTime); if(PeekMessage(&msg, 0, NULL, NULL, PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); } if(gameTimer->deltaTime >= 1.0f / 60.0f) { for(int i = 0; i < gameObjectList.size(); i++) { gameObjectList[i]->Update(); } graphicsEngine->Render(); gameTimer->deltaTime = 0.0f; } Sleep(1); QueryPerformanceCounter(&gameTimer->lastTime); gameTimer->CalculateDelta(); } This is how I'm calculating delta: deltaTime += ((float)lastTime.QuadPart - (float)currentTime.QuadPart) / frequency.QuadPart;

General and Gameplay Programming Programming

Started by SolDirix November 12, 2013 08:40 AM

18 comments, last by tonemgub 10 years, 5 months ago

samoth

9,833

November 13, 2013 09:53 PM

That doesn't help much, for two reasons:

1) Most games already use the highest process&thread prioritiy available

2) The thread becomes active between intervals of the system timer - you can only hope that it becomes active sooner than later.

I still say that the waitable timers are just software timers backed by the system timer

No, no, and no.

1) Only games made by incompetent programmers use the highest process and thread priorities available. Microsoft explicitly discourages from doing so, as it will seriously interfere with system operability.

2) A thread with a boosted priority will in any case be scheduled before any other thread with the same priority (without boost) is scheduled, and it will in any case prevent such a thread from entering its second quantum. On Win8 onwards, it will interrupt a thread in the middle of a quantum.

3) While that is partly true -- historically --, it is not true for Windows 7 any more, and even less so for Windows 8, which like Linux 3.10 uses a "tickless" kernel ("mostly tickless" is a more accurate naming). A waitable timer schedules a hardware timer, which fires an interrupt when the time is up. It then makes the thread ready and boosts the thread priority, and reschedules. Sleep simply sets the thread to ready when the scheduler next runs, which still happens periodically in a "tickless" kernel (but a lot less often).

L. Spiro

25,818

November 14, 2013 05:33 AM

The system timer has nothing to do with the mouse, or any other bus-connected device. Devices have their own interrupt that signal the CPU when a hardware event happens

Now you’re getting it!

Ever heard of a hardware timer? When it expires it causes an interrupt and signal, just like a mouse!

So, WaitMessage will return when either the timeout expires (as timed by the system-timer)

No. A message sent is always a signal, and signals are always virtually immediate (measured in microseconds, not milliseconds).

In a standard-issue timer, the delay between its trigger time and the Windows message to handle it (WM_TIMER) is off by a large amount simply because the timer itself used a low-resolution clock for its trigger, not because the signal (message) was delayed by a low-resolution clock.

If you set a thread to wait for a signal and then you do a task and then send the signal, that thread will get the signal almost immediately, and all Windows messages are based on the signalling scheme.

Hardware timers cause an interrupt that causes a signal that cause an almost immediate response.

Since most systems only have one hardware timer, the operating system uses it to signal the next-in-line timer (taking advantage of the hardware interrupt), then reset the hardware timer to the amount of time left on the next-to-fire timer etc., allowing any number of timers to trigger via hardware interrupt, regardless of the system timer.

This can introduce a slight amount of drift as shown in Hodgman’s experiments; his fired in 0.1 milliseconds worth of drift, but in fact that is just the accumulated error as the operating system readjusts the hardware timer for multiple other timers before finally getting to his. If his is the only timer on the scheduler, it would likely have had a drift of only about 10-20 microseconds.

And then there are of course regular timers which are indeed based off the system clock. These exist as a power-saving way to implement timing when drift is not such a large issue, because the more timers you put on the hardware timer the more drift you get, and this it is generally assumed that the hardware timer should have as little drift as possible.

Hence the only way to use the hardware timer is via SetWaitabeTimer().

so why would they make only the waitable timers high-performance, then?

Read above.

Everyone (mostly game developers) would just start using them

Most people don’t even know about SetWaitableTimer().

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

tonemgub

2,009

November 14, 2013 10:16 AM

Yeah, I already knew about hardware timers (plural, because there are more of them, not just one). I'm not just "getting it now". :)

The main timer hardware (that the system timer is based on) is the Programmable Interval Timer.

There is also the HPET, which is what I think you're referring to as "hardware timer". But for some reason, I always thought it was just a counter, not a programable timer - looking at Wikipedia now, it seems to besaying that the HPET does have programmable capability. :)

It would be really nice if MSDN would mention which of the hardware timers are used by the timing/scheduling APIs (and how). Is SetWaitableTimer the only one that uses the HPET, or do you know of any others?

Thanks, guys.

QueryPerformanceCounter Win32 timer slower than normal

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

QueryPerformanceCounter Win32 timer slower than normal

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines