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.
