Seperate Input Thread

The main problems with having input in the same loop as rendering is that the input becomes jerky when framerates drop.
If you decouple the mouse cursor from the main loop it will appear smooth at all times (kind of) - thus fooling the player that the game is running smoother!

/Robert

DirectInput uses a separate thread for handling input. So when ever you create a DInput device you'll have another thread receiving the input from mouse/keyboard etc. I don't know if you are working on DInput or not, but according to DX documentation, it is discouraged to use DInput - especially since the separate thread will provide some extra overhead.

If you run your rendering and game logic loop in the same thread already, separating the input to another thread won't help.

-An input event cannot change game object states when ever they occure.
For example, consider a situation where the input event would change the relation of objects (such as dropping a weapon or so). If your object handling is well made, it won't be possible while traversing the object tree, so your input event wouldn't have any effect (not nice). Otherwise, if the event could actually change something it might lead to program crashes or other strange behaviour (not nice either).

So, practically this means that you'll need to collect all the input events to a buffer and then process them when it is ok for the engine to change game object states.

I am not familiar with separated game logic / rendering threads, but in that case I'd guess that the game logic thread would be reading the input events.

Cheers!

Awesome thanks for all the info.

I'm using OpenGL not DX, but I think leaving the input in the game logic thread simplifies "locking" the object tree when it shouldn't be changed.

Thanks again everyone!

I have low level hooks that detect input, and they are in a different thread. To collect the input and make something happen I send my game logic class small messages that tells it a key was pressed, from the hooks. Those messages are stored in one of two buffers, I switch which buffer I'm using every frame. Then my game logic does what it want with the message, I send them to a class that is specialized on grabbing pressed keys and doing stuff from that.

The reason I'm using hooks is that it's the most comfortable way I know (I don't know DirectInput ;) ) to capture input. The fact that they are running in seperate threads just make the whole thing a little bit more complicated.

I'm not sure if this increases the framerate of the game, it depends on what you are doing to check input at the moment. I don't know how fast GetAsyncKeyState() is, and I think that processing windows messages will give you about the same framerate.

Hope this helps a bit, my suggestion is that if your way works - keep it.

Daniel