architecture – Is Dedicating A Thread To Inputs A Good Idea In Game Design?

You don’t gain any benefit from polling for input faster than you act on it.

Even if you read the input early on your input thread, it’s just going to sit in queue for the next game update step to pick it up, accomplishing nothing in the meantime.

So the situation is equivalent to the game update thread just reading all the input since the last update, and applying it directly to the current update step.

Keeping input on the game update thread is architecturally simpler, and avoids the risk of variations in thread timing making your controls feel inconsistent. (eg. with a 200 hz input loop and a 120 hz game update loop, sometimes your update loop gets 2 input samples, sometimes it gets 1, creating a beat frequency in your control responsiveness)