Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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

I am struggling to fully understand the responsiveness argument suggesting to run the game loop on a separate thread other than main thread.

When OS sends a user event (touch, mouse move, etc.) it will be handled within the main thread. Then you would have to forward this event into a game loop thread where this event usually is placed into a queue. The OS may think that event was processed instantly, but user will still have to wait until event is actually processed.

In this case there is an inevitable latency before the event gets processed.

It is exactly the same latency when event is processed in the main thread, but in this case OS can detect the latency.

Is it this latency that separate thread game loop is trying to avoid, or is there anything else?

share|improve this question
You'd have to know exactly what problem is being solved by moving the game loop to a separate thread. Do you have a source for the "the responsiveness argument"? You're asking people to argue one side of an argument here, without fully knowing what the argument is about. – Byte56 Feb 13 '14 at 17:02
@Byte56, I am not asking to argue :) I can't find a source making this suggestion, I came under assumption that it is a common practice by reading info I've found on the web. Simply I'm trying to understand where the responsiveness gains are when a game loop runs on its own thread. I have pointed one out in my question, and would like some reassurance that it is a correct one. – Kimi Feb 13 '14 at 17:44
Right, not argue in an emotional sense, argue as in present facts to assert one side of a debate as the correct side. If you don't see the benefits of using a separate thread, don't do it. I wouldn't say it was a common practice. Multithreading typically introduces more problems than it solves in my experience. The benefits of using threading depend on the problems you're trying to solve, the technology stack you're using and the requirements of your game. This makes it near impossible to provide a definitive answer as to why a separate thread should be used. – Byte56 Feb 13 '14 at 17:49
up vote 2 down vote accepted

One important point - when you're using eg. DirectX, you really, really don't care about the main thread. Let it be as free as possible, it doesn't do anything. All the inputs and outputs are processed separately from the UI thread, so why tie them to it? That's only going your window to stop responding if your rendering / updating is too busy. Also, yes, multithreading is complicated. But that's not the case here - you don't want your threads to interact, so everything is fine - they don't access each other's resources, and they don't need to communicate save for a quit message :)

Let's explore Windows + DirectX more:

You usually want a fairly predictable update (/frame) rate. But at the same time, you want to process windows messages (that's the things like "move the window", "resize the window", "press Alt-F4"). Now, you want to process an incoming windows message as soon as possible. Why? Because they contain important things, like WM_QUIT. And Windows will report your application as "not responding" if you, well, don't respond to the windows messages.

Another important thing is that when you use SendMessage to send a windows message, you're blocking the sender, until you actually read the message. If you have WM processing tied to your game loop, this can mean many issues (since the update loop will usually take a lot of time to go through, say 16ms for a 60 FPS game, while WM processing is usually very much under-ms). If someone eg. sends key presses to your application (like some macro program), there's a big difference between receiving 100 WM_CHAR messages in a row and taking 16 ms to process each one.

All that said, this is incredibly platform dependent. On Windows with DirectX, I'd advise to really separate the WM processing from the game itself. The only cases where you actually want them to be tied are those like "I want to resize the game window". Different platforms have different best behaviours and different constraints.

share|improve this answer

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.