Say I design my game targeting a specific PC to run it on 120 frames per second. And say I need to get Input data from the controller at a frequency of 800 times per second, and feed that input data to the game thread for it to choose whatever manipulation it wants to do with that data.

Is that a really good option for me to try to design, or are there major negative aspects to that concept at face value?

End of the question.

Additional notes of relevance: In a highly competitive online action game. I would like to handle inputs much more frequently than 120, 140 or 60 fps of game thread. For two reasons, one inside the game thread itself I would like to know very frequent input data calculated to help give the desired input value for pure game design reasons. The second reason is that the input thread will have close functionality to networking logic where I want to send inputs prior to when they will be implemented in the local game logic itself (some 20-25 ms prior) and I want to send them the moment I see fit despite at what point in the game frame we currently are. A frame of 8 ms, 16ms, or 30 ms is a very long period for our game logic to tolerate over a network. The game is built sufficiently well as an offline prototype and now it is being put under the hammer of online limitations and specifications. Threading inputs and networking outside of the game main thread seems on paper a very promising option. I want to know whether it is feasible to pursue. I really need an opinion from an expert, or at least a knowledgeable programmer because the issue is such a pivotal decision in my work.

  • \$\begingroup\$ Bear in mind that your game update rate does not need to be limited to your framerate. If your game logic can tick 120 times a second, even if you're only rendering 60 frames per second, then you handle all inputs within 8 ms of when they were received. This is well within the variance you can expect from network communication, so shaving off an extra 1-3 milliseconds here is unlikely to make a measurable difference - the total latency is dominated by the network. If you find your replication isn't sufficient at 120 ticks per second, try editing your question to ask about that root problem. \$\endgroup\$
    – DMGregory
    Commented Nov 22, 2020 at 23:10
  • \$\begingroup\$ The exact reason for the need for another thread for the input is that "only" the input needs to be harvested in a really high and stable rates, the rest of game logic is not. This issue stems from my attempt to design a deterministic logic, with high speed game objects and it is really sensitive, so that I need to secure the offline-input side of the equation, before running in way less controllable network environment itself. I honestly see the question is very suitable to the problem at hand, albeit I wrote it after an entire day of work which may have made it not well worded. \$\endgroup\$
    – Physician
    Commented Nov 22, 2020 at 23:26
  • \$\begingroup\$ It sounds to me like you've made up your mind about what solution you believe to be appropriate here, and are not especially eager to entertain other perspectives. That's valid - it's your game, you know it best, and you can implement it the way you want. But in that case, I think you'll get more value from proceeding with your implementation without waiting for the blessing of us Internet randos. 😉 \$\endgroup\$
    – DMGregory
    Commented Nov 22, 2020 at 23:34
  • \$\begingroup\$ I am trying to have an opinion of someone that is really expert in multithreading in game programming. What you mentioned about running the game logic different than the rendering rate is really interesting. I will certainly look into that before going to multithreading. Thanks for your time. \$\endgroup\$
    – Physician
    Commented Nov 22, 2020 at 23:52

1 Answer 1


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)

  • \$\begingroup\$ You didn't answer the question. You assumed a whole lot of assumptions in order to make the concept non beneficial. If I simply took the average of twenty inputs over say 8 ms, it is a different input completely from one each 8 ms of game thread, it is day and night for some types of games. You my friend didn't help. \$\endgroup\$
    – Physician
    Commented Nov 22, 2020 at 21:03
  • 1
    \$\begingroup\$ Maybe you'd like to edit your question to include that detail, to ensure you get answers about your specific use case. \$\endgroup\$
    – DMGregory
    Commented Nov 22, 2020 at 21:17
  • \$\begingroup\$ OK, I will thanks for your help. \$\endgroup\$
    – Physician
    Commented Nov 22, 2020 at 21:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .