W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [Gamepad] Liveness of Gamepad objects

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 29 Apr 2014 23:21:41 -0500
Message-ID: <CABirCh8dSbrTYA0D9V6VmSNdCpUViv0EmaRfjkJp27WWUCaqZA@mail.gmail.com>
To: Ted Mielczarek <ted@mozilla.com>
Cc: public-webapps <public-webapps@w3.org>
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek <ted@mozilla.com> wrote:

>  On 4/29/2014 7:28 PM, Glenn Maynard wrote:
>
>   Gamepad objects should definitely be a snapshot.  Otherwise, change
> events could only expose the most recent state of the gamepad.  For
> example, if the user presses a button and then releases it very quickly
> (before the down press gets handled by script), and you fire two change
> events, the script would never see the buttons as pressed.
>
>
> This is a good point--if we have live objects then if we do implement
> change events we'd need to store the state elsewhere. Firefox has
> gamepadbutton{press,release} events and gamepadaxismove events[1][2]
> (behind a pref), they actually do this already but it's not fantastic.
>

There should simply be a "change" event, which is fired when any property
changes.  (Some rate clamping might be needed for analog inputs, which
could change very quickly, but that's an implementation detail.)

My original prototype provided the events mentioned above. The feedback I
> received was overwhelmingly in favor of a polling API instead[3]. I decided
> to go ahead with that (actually Scott beat me to the punch and implemented
> that in Chrome first), figuring we could always spec events in a future
> revision.
>

(Please try to direct conversations here or to the whatwg list, so everyone
has a chance to participate...)

Supporting polling is a separate issue from whether the Gamepad interface
is live or a snapshot.  You definitely want to be able to retrieve a
snapshot of the current state, and as long as you can do that you
automatically support polling.

That is, users can either use polling:

onRequestAnimationFrame = function() {
    // Once we create this, it never changes, so we can compare it the next
time around when it becomes lastGamepadState.
    var gamepadState = navigator.getGamepads();

    // Find differences between lastGamepadState and gamepadState and act
on them:
    for(var i = 0; i < gamepadState.length; ++i)
        processInput(gamepadState[i], lastGamepadState[i]);

    // Save the current state, for comparison during the next frame.
    lastGamepadState = gamepadState;
}

or events:

navigator.onGamepadChange = function(e) {
    var gamepadState = e.state;
    processInput(e.gamepadIndex, gamepadState, lastGamepadState);
    lastGamepadState[e.gamepadIndex] = gamepadState;
}

In either case, gamepadState is a static snapshot.

(Aside: I'm not sure if the top one is correct.  Does
getGamepads()[n].index == n, so that gamepadState[i] always corresponds to
lastGamepadState[i]?  The spec suggests that with "index of the gamepad in
the Navigator", but I'm not sure.  If so, what is getGamepads()[1] if
controller index 1 is disconnected, since you can't reorder the later
items?  undefined?)

-- 
Glenn Maynard
Received on Wednesday, 30 April 2014 04:22:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC