No, it listens to WM_* Windows event messages. Polling means...
Windows messages only arrive when you poll the Windows message queue though, so unless you have an extremely high polling rate (>100Hz), your timestamps are going to be wrong anyway, right?
In a basic game loop that most people use at the start of their learning experience you basically peek into the Windows message buffer and either eat the message or draw the frame.
Unless you purposely limit your framerate with sleeps it likely will be 100 Hz or more, or at least 60 Hz.
Of course the speed at which you can poll depends on your game speed which is why I suggest to move that to another thread and poll for input on the same thread that created the window.
This would be done with WaitMessage(), which will keep the thread on a low priority until an input has arrived and should immediately awaken the thread once it has. You should be able to keep the input thread on the highest priority as well since inside WaitMessage() it shouldn’t just be sleeping but in an “event-waiting” state, so it won’t be hogging the CPU but also won’t get drowned out by the other threads when an event does occur and it awakens.
In this case you aren’t really polling. You should be able to get all events within a millisecond of accuracy.
But there is still another option on Windows since you can get message timestamps (forgot the function).
Though it is tricky to synchronize with your game clock, which you would need to do for smooth integration.
L. Spiro
