Re: [Gamepad] Liveness of Gamepad objects

On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek <ted@mozilla.com> wrote:

> 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?
>

We just implemented gamepad entity "live-ness" in the dualshock-controller
module for node. The discussion is here:
https://github.com/rdepena/node-dualshock-controller/issues/27



Rick