Sign in to follow this  
mark ds

raw input vs getkeyboardstate in windows

Recommended Posts

mark ds    1786
Hello, this is a really simple question (win32 based)

Is their any real reason why one shouldn't use GetKeyboardState, as opposed to the raw input API?

I accept that for a single key GetAsyncKeyState is the better choice. But for 20 odd keys, which is the norm?

regards Edited by mark ds

Share this post


Link to post
Share on other sites
Hodgman    51222
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.

Share this post


Link to post
Share on other sites
sosa    186
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.

[url="http://www.gamedev.net/topic/623538-wm-input-polling-rate/"]http://www.gamedev.net/topic/623538-wm-input-polling-rate/[/url]

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.

Share this post


Link to post
Share on other sites
mark ds    1786
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this