This project is read-only.

How do you ease Keyboard and Mouse input gathering?

Nov 1, 2008 at 3:43 PM
Hi StatusUnknown,

I didn't see how you ease keyboard or mouse input gathering with your PlayerInput class. Could you please post either in the documentation or in the tutorial solution how you see its usage?

My first guess is that we would need to get the InputState property and code ourselves all the logic to know if a key or a mouse button is currently pressed, released or hold... I have a class that already implement this features seemlessly and if you come back to me with such required coding, I would be pleased to share this code with this project. Let me know and I'll submit it to you one way or another... :)

Nov 1, 2008 at 3:53 PM
One other feature that you could add quite easily through the code I produced is the Culture support: based on the Culture set, I can dynamically set if the Keyboard used is QWERTY or AZERTY. I could therefore add other Keyboard mapping support such as Spanish keyboards. ;)
Nov 2, 2008 at 12:17 AM
Edited Nov 2, 2008 at 12:20 AM

Short answer: You are correct.

Long answer: I think you are correct. But I need to think a bit.


I agree with what you are saying.

Firstly, it isn't obvious, but there are also the following method/properties in the UpdateState:


You may have missed these (I don't blame you if you did). These provide buffered access to the XNA gamepad/keyboard/mouse state.

The Input system is by far the oldest part of the API, it predates the whale watch project (it was built for XNA 1) and is also the part I like the least - however it's purpose is very simple. The input 'GetState()' methods in XNA are very slow.

The idea of PlayerInput is simply to wrap up what XNA gives you, but give it to you in an efficient way (although PlayerInput itself is intended to only represent a gamepad). The reason I had to roll my own classes, was because all the setters/constructors in XNA are private/internal.

The benefit is that input is also consistent over the entire update frame. 

The way XNA provides input encourages you to write things like the following, directly in your object update code:

if (GamePad.GetState(PlayerIndex.One).Buttons.A == ButtonState.Pressed) 


Code like this can kill performance (and can be highly inconsistent, as the GetState call can change during a frame). PlayerInput and the properties in UpdateState are intended to prevent people doing this, as it's another performance trap in XNA.

I took me a while to realise what you meant by the non-qwerty support. This is certainly a good idea. Although I'm not sure if this can be detected at run time... (I'll look into it)

Nov 2, 2008 at 1:57 AM
The way I usually test my keyboard or mouse input is by storing the keyboard and mouse states for the previous frame and comparing both key states as for instance:

KeyboardState previousKeyboardState;
KeyboardState currentKeyboardState;

In the XNA Update method:
public void Update(GameTime gameTime)
     previousKeyboardState = currentKeyboardState;
     currentKeyboardState = Keyboard.GetState();
    if(currentKeyboardState.IsKeyPressed(key) && previousKeyboardState.IsKeyPressed(key))
          // key is hold
    if(!currentKeyboardState.IsKeyPressed(key) && previousKeyboardState.IsKeyPressed(key))
          // key is just released
    if(currentKeyboardState.IsKeyPressed(key) && !previousKeyboardState.IsKeyPressed(key))
          // key is just pressed

But with Xen, this is not possible directly.

As for the QWERTY or AZERTY keyboard support, this is totally doable using the CultureInfo instance throught:

It returns you a CultureInfo instance that you can use to know which keyboard layout is installed.
You only need this for Windows deployment so it shouldn't be an issue as long as you put the code in a #if !XBOX360 ... #endif compiler statement.
I don't have the list of the KeyboardLayoutIds but it should be a good start :)
Nov 11, 2008 at 3:01 AM

Hey. I'd be interested to know what you think of the keyboard updates I've made 1.3a.

I haven't put in an WASD remapping, and I'm not sure if I will. However the keyboard state now is stored as Buttons, which keep the previous value and also tell you things like how long they have been held down for.

Finally, it also correctly uses the windows unicode api's to map things like 'shift-1' into !, etc, which is much more annoying to do than you'd think :-)