the Fiddler's picture

[Input] Add static classes for Mouse, Keyboard and GamePad input

Project:The Open Toolkit library
Version:1.1-2014-01-02
Component:Code
Category:task
Priority:normal
Assigned:Unassigned
Status:closed
Description

These classes should be independent of the GameWindow and usable on their own. Proposed API:

MouseState OpenTK.Input.Mouse.GetState(int index);
KeyboardState OpenTK.Input.Keyboard.GetState(int index);
GamePadState OpenTK.Input.GamePad.GetState(int index);

[Mouse|Keyboard|GamePad]State are structs that encapsulate the state vector of the relevant device at the time when GetState was called. 'Index' is an optional parameter that specifies which device is queried, when multiple devices are connected to the computer. It is not an error to query a device index for a non-existent device: in that case, the state vector will indicate IsConnected = false.

Device indices may not after application startup. For example, if the computer has 3 devices (0, 1, 2) and device 1 is disconnected, the indices of the other devices may not change: they shall remain (0, 2).


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#21

That was the original idea but I don't think it will work out very well in practice. They are meant for completely different use cases: GameWindow input is meant for UIs and gives you a hardware cursor, absolute coordinates, pointer ballistics and basic IME support. The static classes work with raw input and relative coordinates, which is great for first-person shooters but less so for UIs (this is why it is difficult to create a keyboard/mouse-driven UI in XNA).

Fortunately, the GameWindow implementation can be simplified significantly once the new input API is implemented. There will be little code duplication outside of what is necessary for backwards-compatibility.

the Fiddler's picture

#22

Multi-mouse and multi-keyboard are now completely implemented on Windows.

I have updated the implementation to report combined device state when you call GetState() without specifying an index. This is very useful for applications taht do not require multi-mouse/keyboard.

We are still missing multi-keyboard on X11 and an implementation for Mac OS X.

jdomnitz's picture

#23

From what I can tell theres still no way to actually list the available devices is there? Or to even be able to tell how many are available... could this be added as well?

the Fiddler's picture

#24

After my experience with the previous input API, I won't be easily convinced that device lists are a good idea. :)

As far as I can tell, the current system can support anything apart from listing available devices on a drop-down menu:

  • How do you detect devices? By having each player press a button on his selected controller.
  • What happens when a device gets disconnected? You stop receiving updates on that device index.
  • What happens when a device gets reconnected? You start receiving updates on that device index.
  • What happens when a new device is connected? A new device index starts receiving events.
  • How many devices do you need to poll? As many as you wish to support. Device indices are allocated sequentially, so you can detect new devices by polling up to your current max index + 1.

Add an "IsConnected" property and you can also:

  • List available devices.
  • Optionally pause the game when a device gets disconnected.
jdomnitz's picture

#25

Thats a very limited use case.....I tend to think that while openTK is used a lot in games its also used in hundreds of other applications (quite a few of which would be limited by that approach). Personally i'm creating a multi-screen UI where each screen needs to be its own independent zone. Ensuring the correct mice/keyboard gets paired with the correct zone is very important.

Even if you want to stick to the games paradigm, very few games operate the way you describe. Typically, the number of players is selectable up to the number of detected controllers. Should a controller become disconnected the game is paused until its reconnected. I honestly can't think of any game with the ability to vary the number of controllers mid-game.

jdomnitz's picture

#26

Second question....how does all of this work with multi-touch? does that cause any issues?

the Fiddler's picture

#27

Quote:

Ensuring the correct mice/keyboard gets paired with the correct zone is very important.

This is a valid use-case. We need stable device ids, which should be doable - OpenTK queries this information anyway.

Still no device lists, though. :)

Quote:

Even if you want to stick to the games paradigm, very few games operate the way you describe. Typically, the number of players is selectable up to the number of detected controllers. Should a controller become disconnected the game is paused until its reconnected. I honestly can't think of any game with the ability to vary the number of controllers mid-game.

I didn't describe how games behave, I tried to describe how they can use the API to implement the desired behavior (e.g. pause until reconnection). You don't need to check for new devices if you don't wish to, it's up to you.

Many arcade and console games allow players to join in mid-game.

Quote:

Second question....how does all of this work with multi-touch? does that cause any issues?

I guess it depends on the OS and the drivers, but my current laptop doesn't have multi-touch so I can't test this.

For instance, Synaptics touchpads don't report zone scroll events in raw input. The drivers probably synthesize these events at a higher level and send them directly to the application in focus.

jdomnitz's picture

#28

Thats fine...I just think requiring every user to press a button on the controller for it to be detected seems really backwards considering we have access to detailed information about the available devices from the time the app is started.

the Fiddler's picture

#29

Yeah, but that's not what I said. :)

I suggested pressing a button as a means to map a controller to a user application-side. You don't have to do this - the controller is detected and available regardless. I just think it's a sensible approach.

I will try to expose the device name and connection status, too.

jdomnitz's picture

#30

Sounds Good.... just to double check-are there plans for an XInput2 keyboard as well? The spec says keyboards like pointers can be mapped individually and theres a rawkeypress and rawkeyrelease event although I can't seem to find any specifics on them.