Handling the game loop with OS timers - windows

Question

A simple game loop runs somewhat like this:
MSG msg;
while (running){
if (PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE)){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
try{
onIdle();
}
catch(std::exception& e){
onError(e.what());
close();
}
}
(taken from this question)
I'm using windows as an example here for the sake of the example, it could be any platform. Correct me if I'm mistaken, but such a loop would use 100% of a cpu/core (uses 50% of one core on my computer) since it's always checking for the state of the running variable.
My question is, would it be better (performance-wise) to implement the game loop using the OS' (in the example Windows) timer functions, setting the required interval according to the desired number of ticks of game logic wanted per second? I ask this because I assume the timer functions use the CPU's RTC interrupts.

Answer 1

Typically, a game will keep drawing new frames all the time even when the user does not do anything. This would normally happen where you have your onIdle() call. If your game only updates the window/screen when the user presses a button or such, or sporadically in between, then MSGWaitForMultipleObjects is a good option.
However, in a continuous-animation game, you would normally not want to block or sleep in the render thread at all if you can help it, instead you want to render at maximum speed and rely on vertical sync as a throttle. The reason for that is that timing, blocking, and sleeping is unprecise at best, and unreliable at worst, and it will quite possibly add disturbing artefacts to your animations.
What you normally want to do is push everything belonging to a frame to the graphics API (most likely OpenGL since you said "any platform") as fast as you can, signal a worker thread to start doing the game logic and physics etc, and then block on SwapBuffers.
All timers, timeouts, and sleep are limited by the scheduler's resolution, which is 15ms under Windows (can be set to 1ms using timeBeginPeriod). At 60fps, a frame is 16.666ms, so blocking for 15ms is catastrophic, but even 1ms is still a considerable time. There is nothing you can do to get a better resolution (this is considerably better under Linux).
Sleep, or any blocking function that has a timeout, guarantees that your process sleeps for at least as long as you asked for (in fact, on Posix systems, it may sleep less if an interrupt occurred). It does not give you a guarantee that your thread will run as soon as the time is up, or any other guarantees.
Sleep(0) under Windows is even worse. The documentation says "the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately". Reality has it that it works kind of ok most of the time, blocking anywhere from "not at all" to 5-10ms, but on occasions I've seen Sleep(0) block for 100ms too, which is a desaster when it happens.
Using QueryPerformanceCounter is asking for trouble -- just don't do it. On some systems (Windows 7 with a recent CPU) it will work just fine because it uses a reliable HPET, but on many other systems you will see all kinds of strange "time travel" or "reverse time" effects which nobody can explain or debug. That is because on those systems, the result of QPC reads the TSC counter which depends on the CPU's frequency. CPU frequency is not constant, and TSC values on multicore/multiprocessor systems need not be consistent.
Then there is the synchronization issue. Two separate timers, even when ticking at the same frequency, will necessarily become unsynchronized (because there is no such thing as "same"). There is a timer in your graphics card doing the vertical sync already. Using this one for synchronisation will mean everything will work, using a different one will mean things will eventually be out of sync. Being out of sync may have no effect at all, may draw a half finished frame, or may block for one full frame, or whatever.
While missing a frame is usually not that much of a big deal (if it's just one and happens rarely), in this case it is something you can totally avoid in the first place.

Answer 2

Depends on who's performance you want to optimize for. If you want the fastest frame rate for your game, then use the loop you posted. If your game is full screen, this is likely the right thing.
If you want to limit the frame rate and allow the desktop and other apps to get some cyles, then a timer approach would suffice. In Windows, you would simply use a hidden window, a SetTimer call, and change PeekMessage to GetMessage. Just remember that WM_TIMER intervals are not precise. When you need to figure out how much real time has elapsed since the last frame, call GetTickCount instead of assuming that you woke up exactly on the time interval.
A hybrid approach that works well with respect to games and desktop apps is to use the loop you posted above, but insert a Sleep(0) after your OnIdle function returns.

Answer 3

MSGWaitForMultipleObjects should be used in a windows game message loop as you can get it to automatically stop waiting for messages according to a definable timeout. This can throttle your OnIdle calls a lot while ensuring that the window responds to messages quickly.
If your window is not full screen then a SetTimer calling a timer proc or posting WM_TIMER messages to your game's WindowProc is required. Unless you don't mind the animation stalling whenever the user, for example, clicks on your window's title bar. Or you pop up a modal dialog of some kind.
On Windows there is no way to access actual timer interrupts. That stuff is buried away under many layers of hardware abstraction. timer interrupts are handled by drivers to signal kernel objects, that user mode code can use in calls to WaitForMultipleObjects. This means that the kernel will wake up your thread to handle a kernel timer associated with your thread when you called SetTimer(), at which point GetMessage/PeekMessage will, if the message queue is empty, synthesize a WM_TIMER message.

Answer 4

Never use GetTickCount or WM_TIMER for timing in a game, they have horrible resolution. Instead, use QueryPerformanceCounter.