Re: [w3c/gamepad] Add device orientation support (Issue #211)

JibbSmart left a comment (w3c/gamepad#211)

Hi! I'd love to see this supported in browsers. I've been really impressed by the capabilities of web apps and games in particular, but the lack of gamepad motion sensor support is a deal-breaker for some genres of games. It strikes me that one can make an impressive modern 3D shooter / RPG / driving game / etc that's playable in one's browser, and it'll largely play the same as a downloaded-and-installed PC or console game... with the notable exception of **no way to implement standard gyro aiming**.

The standards for gyro aiming have improved a lot over the last decade and solidified with a few outstanding mainstream examples (Fortnite (my own design and implementation), Call of Duty, No Man's Sky, and The Finals, to name a few exemplars).

All standard console controllers in over a decade that have motion sensors (PS4, PS5, Switch, and Switch 2) are supported by Steam's built-in input remapper by providing gyro-to-mouse conversion for games that don't natively support gyro. But games are also increasingly supporting gyro aiming without relying on external tools, with Fortnite (my own design and implementation), Call of Duty, No Man's Sky, and The Finals being a few notable examples.

I know first-hand that SDL includes motion sensor support for PS4, PS5, and Switch 1 controllers, but haven't seen for myself whether it does the same for Switch 2 controllers yet. SDL and other good input libraries scale and map the inputs to all have matching coordinate spaces and units, so the application can use the sensor inputs the same regardless of its source.

The **minimum useful version** for the web standard would simply give access to uncalibrated, unfiltered gyro (angular velocity) and accelerometer (linear acceleration, without filtering out gravity) vectors. Exposing just these would give developers enough to implement high quality gyro aiming / controls for games. It seems to me the sensible approach would be to use radians per second for angular velocity and metres per second squared for linear acceleration, since those are used in the mobile device APIs. The local coordinate system can probably be based on something similar (right-handed, y-up), but the important thing is simply that it's consistent between different controllers and different browsers.

There are a bunch of other useful features to explore, as seen in the example of [JoyShockLibrary](https://github.com/JibbSmart/JoyShockLibrary) (which I'm not currently maintaining, so I'm only pitching it as an example to look at rather than a suggestion for any implementers to use it). But I wouldn't want discussion around additional features to slow down setting a simple standard of exposing gyro and accelerometer sensors without processing/filtering apart from mapping and scaling to a consistent local coordinate system.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/211#issuecomment-3734031741
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/211/3734031741@github.com>