rust-gamedev / wg

Coordination repository of the Game Development Working Group
504 stars 10 forks source link

Input Handling #69

Open msiglreith opened 4 years ago

msiglreith commented 4 years ago

State of Ecosystem

An (non-exhaustive) overview where the Rust ecosystem is currently standing in this regard. Focused on

Issues

Ralith commented 4 years ago

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.

distransient commented 4 years ago

@Ralith question from input layman, does the Steam input API work on OpenXR bindings or its own thing entirely?

Ralith commented 4 years ago

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.

aclysma commented 4 years ago

See also: #34 "You know what we don't have? A good input abstraction crate"

Lokathor commented 4 years ago

Related, https://github.com/rust-gamedev/wg/issues/77