Return to Answer

Take a classic game like Super Mario Bros. If you were to port to modern hardware and separate input handling in a separate thread from rendering, then chances are that it would feel no better or very possibly even worse when the control input response is no longer so precisely timed to frame output. It's either going to feel as right or worse (as though the frame display is somewhat a bit off from what the user is pushing on his gamepad) since we're basically just separating a thread doing very little only to communicate the results of what the user inputs to other threads just to basically cause Mario to jump or something of this sort. Even if the cost of that can be made dirt cheap from the time a button is pushed to starting to show the results of that in a frame, it's still jumping through hurdles for no real practical reason when you can make a game like this very interactive while the basic frame output and user input are being done in the same thread*.

Take a classic game like Super Mario Bros. If you were to port to modern hardware and separate input handling in a separate thread from rendering, then chances are that it would feel no better or very possibly even worse when the control input response is no longer so precisely and consistently timed to frame output. It's either going to feel as right or worse (as though the frame display is somewhat a bit off from what the user is pushing on his gamepad) since we're basically just separating a thread doing very little only to communicate the results of what the user inputs to other threads just to basically cause Mario to jump or something of this sort. Even if the cost of that can be made dirt cheap from the time a button is pushed to starting to show the results of that in a frame, it's still jumping through hurdles for no real practical reason when you can make a game like this very interactive while the basic frame output and user input are being done in the same thread*.

In my blunt opinion this is like a ridiculous way to use threads because what does user input involve? It involves checking to see if the user pressed/release some key on the keyboard or pushed/release some button on a mouse or joystick (and normally I wouldn't use a blocking function like getch for this). Which means the thread has little work to do besides just waiting for an event/interrupt to occur or, worse, just polling and doing nothing until the user actually does the something with his/her input devices. And it's not such a big deal if a thread is mostly sleeping and doesn't have much to do, but it becomes a bigger deal if there's a latency involved in communicating from one thread to the next when a very real-time response is needed.

In my blunt opinion this is like a ridiculous way to use threads because what does user input involve? It involves checking to see if the user pressed/release some key on the keyboard or pushed/release some button on a mouse or joystick (and normally I wouldn't use a blocking function like getch for this). Which means the thread has little work to do besides just waiting for an event/interrupt to occur or, worse, just polling and doing nothing until the user actually does the something with his/her input devices. And it's not such a big deal if a thread is mostly sleeping and doesn't have much to do, but it becomes a bigger deal if there's a latency involved in communicating from one thread to the next when a very real-time, consistently-timed response is needed.

All right, just to contradict myself a bit for exceptional cases and yield to any who might disagree with this opinion, I could see more of a case for a separate user input thread in even a simple typing game: those games where you have to type what you see on screen as fast as possible. In those cases the nature of the game input might not be so directly tied to frame output. Even if the game can display its frames at 30+ FPS, a user super fast on the keyboard might type faster than this or hit two or more keys in between the display of one frame to the next, and there it might be useful to queue up those results in some producer thread and have a consumer pop it off and handle all the keys pressed in between those two frames. That's a very different game from Snake though or Super Mario or something where it's not necessarily useful to queue up what the user has pressed in between frames (those games tend to benefit more from just knowing when a button is down/up for a particular frame as opposed to queuing up key presses like an input field). I'm taking very much into account the specific nature of the type of game being developed in my answer and also the simplest, most practical solution for such an application that's likely to yield desired results with minimal fuss.

All right, just to contradict myself a bit for exceptional cases and yield to any who might disagree with this opinion, I could see more of a case for a separate user input thread in even a simple typing game: those games where you have to type what you see on screen as fast as possible. In those cases the nature of the game input might not be so directly tied to frame output. Even if the game can display its frames at 30+ FPS, a user super fast on the keyboard might type faster than this or hit two or more keys in between the display of one frame to the next, and there it might be useful to queue up those results in some producer thread and have a consumer pop it off and handle all the keys pressed in between those two frames. That's a very different game from Snake though or Super Mario or something where it's not necessarily useful to queue up what the user has pressed in between frames (those games tend to benefit more from just knowing when a button is down/up for a particular frame as opposed to queuing up key presses like an input field). It's like if the user presses down and then up key in between one frame to another, there's nothing for the game to do except ignore one of those two keys and start moving the snake in one of those directions when it comes time to handle the game logic and display the frame. I'm taking very much into account the specific nature of the type of game being developed in my answer and also what I believe is the simplest, most practical solution for such an application that's likely to yield desired results with minimal fuss.