Why game loop should be running on a separate thread?

Question

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?

Answer 1

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.

Answer 2

Main thread, (aka Render thread, UI thread) is actually actuator thread, which task is to take some situation and display it to user. In simple fulscreen\realtime\embedded cases (when you run game close to hardware - when you have linux kms or android) its just that. In more complicated cases like windows or xorg it also processes some window-related events, such as resize window\viewport or move it. Also frame rendering time relies on graphics\shader computational heaviness - more triangles in view and complex shaders results in frame rate drop and its variability. So its output, or consumer thread.

On other hand, when running game loop (aka physics loop, logic loop) you want to stick it to some precise fixed time marks, running at fixed rate to get predictable physics integration (ODE solver with fixed dt) and event sampling. It typically processes events like mouse/keyboard/network input, and timer input, and when timer events occurs it calculates next frame, predicts positions and velocities, and updates situation, which is then presented to renderer thread and sent over network. So it is "input and processing" or producer thread. Offloading and separating input from processing is usually hard to achieve task, resulting in greater latencies.

Generally, you want to run your logic thread at faster rates and fixed rates than render thread which may be slower and have variable jitter. Then you may easily apply lockless producer-consumer interthread synchronisation schemes, using triple buffering. Personally i recommend 120+ fixed fps logic thread (usb poll rate is 125 hz, and windows sheduler works best with 64 or 128 fps timers), and render thread can be 40+ fps for comfortable playing experiences and very low input lag.