raw input vs getkeyboardstate in windows

Usually you listen to the input events in order to generate your own representation of the keyboard state, for example, an array of 256 bools.
GetKeyboardState returns this kind of array, but it still requires that your program has actually been processing the keyboard events as they come in anyway, so it doesn't seem very useful if you're already doing this yourself.

GetAsyncKeyState is a terrible idea in most games, as it's possible for keypresses to "fall between the gaps" -- if you press (& release) a key very quickly, then it won't show up as a press at all with GetAsyncKeyState.

The Raw Input API is a bit complicated if you don't know how it works behind the scenes. Pay special attention to buffered commands that if you don't process will hang your application. The link below has a very good description of how to use WM_INPUT.

http://www.gamedev.net/topic/623538-wm-input-polling-rate/

On the other hand, if you are developing for windows only then there is really no reason not to use standard windows messages (WM_KEYDOWN, WM_LBUTTOMDOWN, etc.) unless you need gamepad support which then DirectInput makes sense.

Hope this helps.

Since I posted, I have read many of the threads on input. There's some good information available.

Does this seems like a good [simplified] approach...?

Main thread creates window and processes all input. Also handles player collision detection against the world/nearby characters/other moving objects.
Rendering done in a seperate thread, which takes a snapshot of player position and view direction from the main thread.

This would allow for high resolution keypress detection and mouse movement decoupled from the frame rate.

Thanks