Jump to content
  • Advertisement
Sign in to follow this  
lochnator

MessageLoop for handling user input

This topic is 909 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

According to microsoft documentation on handling user input the advise to no longer use directinput and instead use the message loop to perform input handling/processing.  I'm confused because in most of my books it states that using the regular message processing for handling input..WM_* messages is to slow for commercial quality games.  It also recommends using GetKeyStateAsync() every frame to query the state of the keyboard and mouse.  Does anyone have any experience to when to use wm_* message handling vs GetKeyStateAsync().  What the are pros and the cons to each.

Share this post


Link to post
Share on other sites
Advertisement

You can see the WM_* approach as more of a passive approach while the GetKeyStateAsync strategy is active. In the WM_* situation, your game goes on it's own business and counts on the operating system to tell it when the state of the keyboad changes, whereas with the GetKeyStateAsync approach it's your game that is constantly asking the operating system if a key is being pressed.

 

For that reason, WM_* has a net advantage over GetKeyStateAsync in a low frame-rate situation. This is because Windows doesn't care about your frame rate when it handles a key press: it will add the key to the message queue and your game can handle it whenever it wants. Your game probably still reads the message loop once per frame, but it won't have missed any keyboard event when the message queue will be empty. If you use GetKeyStateAsync, your game will only sample the keys once per frame, so if you're running at a low frame rate and the player is typing something fast in the chat box, it's going to miss some key presses and the player is going to have a very frustrating typing experience.

 

Both of those approaches may be slower than sampling the state of the keyboard's 200-something keys at once using DirectInput, but if you're at the point where it's keyboard input that is the game's bottleneck, you probably have the fastest rendering engine in the world, and like I said, reading the keyboard's state once per frame has it's issues on low frame rates. That said, I'm not sure why WM_* would be slower. Regardless of whether you process them, the messages are still sent to your message queue, and if you don't treat them, DefWindowProc() will do it for you, so you may as well treat them in the message queue if it's a good place for you to do it.

Edited by Bearhugger

Share this post


Link to post
Share on other sites
If you want to treat the keyboard as an array of buttons (i.e. not text input) and you want unmodified mouse input (i.e. no cursor ballistics) you should generally be using Raw Input for input handling on Windows.

If you are doing text input, then you'll use the WM_CHAR and related inputs so Windows can do all the complicated text input processing for you (like dead characters).

If you are displaying a mouse cursor, then you'll want to use the standard WM_MOUSEMOVE and similar events so proper ballistics can be applied to the cursor.

Note that there is no reason your game can't handle both raw input and Windows message input and switch between the two as necessary. For example, using raw input for a shooter, but then switching to the Windows messages when opening a chat box or a menu.

If you want to support XBox-compatible controllers, you can make things a little simpler and use XInput.

You probably don't need to use GetAsyncKeyState for the reasons mentioned above.

And you certainly never want to use DirectInput which these days is not only deprecated and can be removed at any time, but is a heavyweight wrapper around Raw Input anyway.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!