- From: Ted Mielczarek <ted@mozilla.com>
- Date: Tue, 29 Apr 2014 10:39:36 -0400
- To: WebApps WG <public-webapps@w3.org>
The only major issue that needs to be fixed in the Gamepad API spec currently is the liveness of Gamepad objects[1]. Currently this is implemented differently in Firefox and Chrome--Firefox uses "live" Gamepad objects, in that you can take the .gamepad property from a GamepadEvent or a Gamepad from navigator.getGamepads(), assign it to a variable, and check its state on every pass through the event loop to get the latest values of .buttons[]/.axes[]. Chrome uses "snapshot" Gamepad objects, so the Gamepad you get from navigator.getGamepads() is static, and you have to call getGamepads() on every pass through the event loop to get the latest state of the controller. I obviously have a bias towards what I've already implemented, but I can see the appeal of both approaches. With the "live" approach you can take a Gamepad object and assign it as a property of another object and use it that way, like "player.input = gamepad", which makes it easy to manage Gamepad input as part of other code. With the "snapshot" approach you can easily save an old snapshot so that you can compare two snapshots and see what's changed. (Additionally as an implementation detail this maps very well to the Windows XInput API, which is a polling-based API.) Does anyone have any feedback on which of these seems more natural? Is there any precedent in the web platform to prefer one approach over the other? -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434
Received on Tuesday, 29 April 2014 14:40:05 UTC