Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After noticing some timing descrepencies with events in my code, I boiled the problem all the way down to my Windows Message Loop.

Basically, unless I'm doing something strange, I'm experiencing this behaviour:-

MSG message;

while (PeekMessage(&message, _applicationWindow.Handle, 0, 0, PM_REMOVE))
    int timestamp = timeGetTime();
    bool strange = message.time > timestamp; //strange == true!!!


The only rational conclusion I can draw is that MSG::time uses a different timing mechanism then timeGetTime() and therefore is free to produce differing results. Is this the case or am i missing something fundamental?

share|improve this question
Just OOC, how often does this happen? Is it really often, or just once every few weeks? – Jeff Jul 22 '10 at 14:38
It's probably once every few events so pretty often but not every time. Thanks for your time! – Adam Naylor Jul 22 '10 at 14:44
up vote 6 down vote accepted

Yes, it does use a different source. If you look at the Windows documentation you will see that you should use GetTickCount/GetTickCount64 to compare against the message time.

If you need any kind of precision, I suggest not relying on the message time - GetTickCount has horrible resolution. (10-16ms)

share|improve this answer
Great advice thanks, but if you want to use the time of a windows message (by comparing it to GetTickCount) how can you ensure high enough resolution? btw quake3 stores the time of the events so they most be useful? – Adam Naylor Jul 22 '10 at 21:04
You can't ensure the resolution, it's up to whatever Windows uses. You'll notice that none of the official documentation says "Yes, that's the counter we're using, and that's how it will be". You could always use QPC or similar to get your own time when you receive the message. That's only a (potentially) serious difference for messages sent via PostMessage - SendMessage is synchronous. What do you need it for? No idea why Q3 stores it. I'm sure they have a reason, but I haven't read the code base. – Rachel Blum Jul 22 '10 at 21:44
Well I need to know exactly when - say - a key is pressed. If i take a reading upon receipt of an event, that will be too late? – Adam Naylor Jul 22 '10 at 22:41
If a 10ms difference really matters, I'd recommend not relying on windows messages. Instead, poll via GetAsyncKeyStatus() – Rachel Blum Jul 22 '10 at 23:29
Really good advice thank you Rachel, i leave the question open and if i don't get any other responses i'll accept this answer. – Adam Naylor Jul 23 '10 at 8:43

I can see two reasons: Either they use different ways of measuring time (as you suggest), or, you have a AMD chip. These can in some cases have timing bugs that you need to either patch through a driver (I think) or handle in your application logic. Google for "AMD timing" and you will probably find something that might be of use.

share|improve this answer
No AMD chip, but good tip thanks. – Adam Naylor Jul 23 '10 at 12:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.