wg
wg copied to clipboard
rust-gamedev
Input Handling
State of Ecosystem
An (non-exhaustive) overview where the Rust ecosystem is currently standing in this regard. Focused on
winitsupports raw input handling on some platforms (exposed asDeviceEvents). These are window independent and, typically, not post-processed by the OS. It is planned to add support for gamepads.openxrsprovides language bindings for the OpenXR API (AR/VR). The specification includes a concept for input mapping via user defined actions and bindings. Planned support for providing an device interface api.gilrsis a Rust library for gamepad support independent of windowing libraries- Platform or device specific libraries like
multiinput,dualshock4, ... amethysthas an input mapping API for mapping device events to custom user actions- Using C libraries like
SDL2for input handling
Issues
- Hard to provide an unified experience for users similar to OpenXR for AR/VR or Unity's latest Input approach, which goes in a similar direction as OpenXR
- Quite a bit of fragmentation, no real overview about the state of each library in this regard
openxrs maintainer here. I think OpenXR's abstract input model is a massive improvement over classical approaches that require an application (or the libraries it ships with) to specifically implement support for different classes of hardware (e.g. kb/m, joystick, xbox controller, head-tracker, etc). However, the forwards-compatibility wins require a runtime containing the actual device support that can be updated by the end user independently of a game. If you don't want to actually use OpenXR, developing and promoting adoption of such a runtime would be a barrier.
Alternatively, it might make sense to work with Khronos to extend OpenXR to be more useful outside of VR, so that existing and future widely-deployed runtimes like Steam can be taken advantage of and mixed-mode apps won't need to deal with multiple APIs.
@Ralith question from input layman, does the Steam input API work on OpenXR bindings or its own thing entirely?
Steam's VR input API can be thought of as something of a prototype of OpenXR's; I am not very familiar with its non-VR predecessor but I expect the story is similar. The Steam OpenXR implementation hasn't shipped yet so I could only speculate as to how thoroughly they'll integrate things at first, to say nothing of long term plans.
See also: #34 "You know what we don't have? A good input abstraction crate"
