I''ve seen various ideas on how to deal with Windows events, from state machines to running your game loop in a seperate thread, but I''m curious as to how the pros go about it. To me, it seems like trying to implement a switch statement covering every possible state a game like Unreal Tournament or Baldur''s Gate 2 could enter into borders on stupidity. At the same time (and maybe it''s just my lack of experience with the subject) trying to run my main loop in another thread is proving a royal pain as well...for some reason the mouse (which I update using the standard WM_MOUSEMOVE and all) becomes EXTREMELY jerky, jumping like 40 pixels when I move it rather than the smooth scrolling I get with input and drawing in the same thread. So, how do the pros do it? I know you''re out there, I''ve seen you post . I''d love to hear any suggestions, or even an idea as to why my mouse scrolling becomes so crappy multithreaded (yes, I have tried putting the mouse drawing code in another thread of its own, no dice). Anthracks

Well, there''s really no "standard" way programmers deal with Windows, but in general, we tend to stay away from using Windows messages unless it''s to deal with Windows specific issues. I have seen several different ways people get around this, but in the games I have worked on, control is usually passed to a different thread.

You need to understand that the Windows event system was designed to handle windowed environments that were driven by mouse clicks for things like office applications. This is a completely different system than a video game which demands a lot of fine control and system resources (this is one of the main reasons why DirectX was created).

Let''s look at your mouse problem. Whenever the mouse is moved, Windows first determines which program should be receiving the input, then it dispatches a message in the program''s message queue. If there are a lot of messages in the queue, it can be quite a while before the mouse input message comes up. On top of that, Windows uses a priority queue, so some messages will bump others back, adding to the delay. For a good example of this, look at the WM_TIMER message. It can become painfully inaccurate even under normal circumstances.

With some messages, Windows will combine like messages in the queue. I don''t know if WM_MOUSEMOVE is one of these, but its likely. Just for the sake of argument, let''s say that it is. If there are several WM_MOUSEMOVE messages waiting in the queue, Windows could combine them so that you only receive the final mouse position. This could be the cause of you jerky mouse.

For your mouse input, try using DirectInput. This way you can poll it at a regular frequency (one per game loop is common).

But there is a bit of trouble getting DirectInput to return absolute coordinates with the mouse which is needed if a person creates a game where the absolute coordinates are need for pathfinding,activation of buttons etc etc.

Not really, my WndProc only handles WM_CLOSE and WM_SETCURSOR messages. It hands everything else off to DefWindowProc().

To get absolute mouse coordinates, I use GetCursorPos() (I dunno how fast this is, but I''ve not noticed any difficulties with calling it every frame). You can also you DirectInput and draw the cursor yourself, but that means that if your framerate is very low (for example in a loading screen) then the mouse is slow (which is bad, since I find that a responsive mouse makes a low frame-rate less noticable, especially in a mouse-driven game like an RTS)

I actually found a decent way around it...I changed the message loop thread to use WaitMessage rather than constantly checking PeekMessage, and now the mouse is almost perfectly smooth. Thanks for the advice guys, I''ll definitely take it into account!

Anthracks

So GetCursorPos() is called in the loops under WM_MOUSEMOVE or in the main function after DirectInput mouse is acquired?