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.
objarni's picture

#1

I like the API!

1. How do you know how many joysticks for example are connected? Loop through the indices, looking for "IsConnected"==false? Just curious, since such a loop is not a big overhead at all (especially since it will only be run att boot-time).

2. What if I connect a game-pad during play? Is there any chance device 1 in your example will become Connected again? Is this an intentional shrink of possibilities, due to OS/hardware restrictions?

the Fiddler's picture

#2

The API is intentionally kept low-level and simple. It resembles the XNA API a lot, but I actually thought this up before looking what XNA did for input. It also lacks events, a fact which allows it to be thread-safe.

With that in mind:

  1. On program startup, loop and detect connected devices.
  2. If a device becomes disconnected, IsConnected becomes false and it stops sending input (meaning it is harmless, your game won't crash). If it is reconnected, it will start sending input again, so you don't have to do anything special to detect this condition.

Depending on the application, you may wish to pause when a device becomes disconnected and ask the user if the disconnection is permanent. Alternatively, you could check for new devices every few seconds and react to any new ones that appear (this is great for arcade/multi-seat games, where a new player could appear at any time). The check is trivial, so it won't consume any CPU time.

I think it makes sense to enforce a maximum limit for 'index'. 8 or 16 should be enough for all uses.

Edit: depending on the OS and the device in question, connecting a device to a different USB slot may cause it to appear on a different index. There's nothing we can do about that...

objarni's picture

#3

I think this would be a really cool addition to OpenTK.

Would connecting two USB mice to the computer be possible, for example? Think of the gaming possibilities.. :)

the Fiddler's picture

#4

Yes, under some conditions (needs support for RawInput on Windows or XInput2 on Linux).

objarni's picture

#5

Is RawInput some DirectX thingie? Or something else? What additional dependencies does it put on an OpenTK app with such functionality (multiple mice input) ?

the Fiddler's picture

#6

RawInput is a Windows 2000+ thingy. DirectInput is an ugly wrapper around RawInput (if supported) or plain WM_* input (if not).

No external dependencies. In fact, OpenTK has shipped with a (disabled) RawInput driver since 0.3.x.

the Fiddler's picture

#7

Status:open» in progress

Initial implementation has been committed to the the input branch:

Features:

  • Keyboard.GetState() and KeyboardState.IsKey[Down|Up] work.
  • Uses Raw Input API (Windows 2K and higher).
  • Deadlock on exit (internal message-only window is not destroyed).
  • Only implemented on Windows at the moment.

The code is far from ready and this branch is not recommended for serious usage at its current state.

the Fiddler's picture

#8

Status:in progress» postponed

This cannot be implemented in time for 1.0.

Mincus's picture

#9

Aha. I just found this after discovering the old OpenTK.Input.Joystick API had stopped working. It still detects the number of joysticks but you can't read any useful values other than that from it.

Is there a timetable for this at all? I was planning on using the Joystick support.

the Fiddler's picture

#10

This is a bug that's been fixed in SVN. (If you encounter any other bugs, please report them!)