Re: [gamepad] Reasoning behind GamepadButton struct

On 2/20/2014 1:35 PM, Brandon Jones wrote:
> I've been working with the Gamepad API implementation in Chrome
> recently, trying to bring it up-to-date with the latest editors draft
> of the spec
> (https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html). While
> generally I feel like it's a good update to the working draft I'm
> puzzled by the decision to change the gamepad buttons from an array of
> floats to an array of GamepadButton structures.
>
> Specifically, it appears to add complexity to the interface and
> implementation without providing new information to developers. I can
> see that if a piece of hardware provided custom deadzones on axes
> which would eventually be interpreted as buttons that it may be
> convenient to use that to determine the "pressed" state, but no
> hardware I know of actually does so. (XInput suggests a trigger
> deadzone of 30/255, but that's an arbitrary guideline and probably
> works well for most similar hardware.) If there is concern about input
> noise providing false positives "presses" for these types of buttons
> it would seem pretty trivial for the browser implementation to apply
> the deadzone internally, and only provide non-zero values above the
> desired threshold.

I made this change to support two major use cases:
1) Analog buttons with known (or at least recommended) threshold values
(like the XINPUT_GAMEPAD_TRIGGER_THRESHOLD you mentioned). While it's
possible for applications to use an estimate here, it felt better to
allow implementations to use API-provided information when available.
2) Controllers with both analog and digital sensors on buttons. The
DualShock 3 (and presumably DualShock 4) controllers are like this--they
have a separate digital switch and analog sensor on most buttons, so you
do legitimately have separate "pressed" and "value" for each button. Not
supporting this means you're throwing away one of the values.

FWIW it looks like Apple has codified this in their Game Controller
framework for iOS/OS X 10.9 as well[1], their GCControllerButtonInput
class has pressed and value members.

>
> I recognize that Mozilla has already implemented the API as described
> in the editors draft, and I don't want to place additional burden on
> them to change it unnecessarily. I'm happy to update Chrome's
> implementation to match, but I want to ensure this is the right
> direction before I do. It's also worth noting that many of the
> existing web apps that use the API (though they are admittedly few)
> expect the buttons to be exposed as floats, and as such updating
> Chrome's implementation will break these use cases. (New fields like
> "mapping" and "connected", on the other hand, can be exposed without
> requiring changes from the app).
Right, which is why I felt like now was the time to make this change,
before anyone shipped a non-prefixed version of the API. I didn't want
to worry about making a non-backwards compatible change in the future
when we had consumers of an unprefixed API. Anyone using Chrome's
existing prefixed API will have to change to support the non-prefixed
version anyway, and it's not much more work to support the GamepadButton
change[2].

>
> I apologize if this has been addressed before, as I've only recently
> started working on the implementation and am not familiar with the
> full spec history. I haven't seen this particular point discussed in
> the archives, however, so I figured it was worth bringing up.
>
My coworker Alan sent a mail about the remaining things we wanted to
clean up in the spec a while ago, and I filed a spec bug on this
issue[4], and we didn't get any feedback either way so I proceeded with
it. Unfortunately we haven't got a lot of feedback on the spec in
general, I'm hoping that will change as we get more consumers.
(Hopefully they don't ask for breaking changes, though!)

Thanks for taking on the task of making Chrome's implementation match
the latest spec, it's appreciated!

-Ted

1.
https://developer.apple.com/library/ios/documentation/GameController/Reference/GCControllerButtonInput_Ref/Reference/Reference.html#//apple_ref/doc/c_ref/GCControllerButtonInput
2. https://github.com/luser/gamepadtest/blame/master/gamepadtest.js#L70
3. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0958.html
4. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388

Received on Thursday, 20 February 2014 20:32:48 UTC