- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 29 Apr 2014 23:21:41 -0500
- To: Ted Mielczarek <ted@mozilla.com>
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <CABirCh8dSbrTYA0D9V6VmSNdCpUViv0EmaRfjkJp27WWUCaqZA@mail.gmail.com>
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