Re: PSA: publishing new WD of Gamepad on April 14

In principle I'm all for events on buttons, but here comes an additional
complication :).

Sometimes buttons are axes. They can be legitimate axes, like the triggers
on gamepads, or incidential axes, like every button on some weird steering
wheel I got. They can also be recognized as buttons by the driver/UA, or
they might wrongly recognized as just axes. The button might have a
physical trigger point (but still be an axis) or it might not have it.
Point is, it's messy.

Which means that it has to be possible to detect axis thresholds manually,
accurately. The driver/browser might do it, or it might not.

So events for axes as they come in from the driver are still useful. But in
order to satisfy both usecases (clearing the event queue for a frame and
getting convenient polled axis values) you need both the polling and the
events.

I'd imagine it could work like this:

navigator.gamepads.onChange = function(event){
  event.gamepad instanceof Gamepad
  event.axis instanceof GamepadAxis
  event.button instanceof GamepadButton
  event.timestamp
  event.type either navigator.gamepads.UP | navigator.gamepads.DOWN |
navigator.gamepads.MOVE
}

var update = function(){
  var gamepads = navigator.gamepads.poll(); // here all the events get
dispatched
  for(var i=0; i<gamepads.length; i++){
    // the usual handling of the polled state, all events have been
processed by here
  }
}



On Fri, Apr 10, 2015 at 6:43 PM, Ashley Gullen <ashley@scirra.com> wrote:

> Well, how about just events for the pressable buttons then? That would
> alleviate most of my concerns with the polling model, and I think you're
> right it's harder to apply it to axes given that there are effectively two
> inputs working simultaneously.
>
> Ashley
>
>
> On 9 April 2015 at 22:29, Florian Bösch <pyalot@gmail.com> wrote:
>
>> The polling model for axes has a significant advantage as I'll illustrate.
>>
>> Suppose you're steering a cursor of some kind in 2 dimensions. That
>> cursor would also draw a trail/line whatever. Here's what happens if you
>> apply this logic on events per axis: You get a staircase. Why? Because the
>> X-axis event arrives, you move the cursor to the side, draw a line, then
>> the Y-axis event arrives, you move the cursor up, you draw a line -> a
>> staircase.
>>
>> If you poll the position of all axes, this effect will not happen, you
>> draw the correct diagonal line.
>>
>> In order to emulate the correct behavior with axis events, you'd have to
>> capture all events, and keep the value of axes separately so you can draw
>> to the appropriate position. But that can't work, because you don't have
>> control over the polling behavior, that is, you don't know when all events
>> are processed.
>>
>> This problem is broadly in the category of correlated event updates, and
>> polling the status (of at least all axes) at a given time solves this
>> nicely. So this functionality should not go away. In fact, it could be well
>> argued that even if you do dispatch events (where they're primarily useful
>> as in buttons), you should still be able to initiate the poll as for when
>> all events are delivered (instead of having them delivered at an
>> unopportune/uncontrolled time).
>>
>> The main drawback of not having events isn't that you'll have to keep the
>> state separately. That's easy. The main problem is that because multiple
>> events make up one final state, you can miss things, such as a button press.
>>
>> On Thu, Apr 9, 2015 at 11:15 PM, Ashley Gullen <ashley@scirra.com> wrote:
>>
>>> Why doesn't the Gamepad API fire events for button pushes or axis
>>> movements? For example when pressing a mouse button or moving the mouse the
>>> browser fires "mousedown" and "mousemove". The Gamepad API however requires
>>> you to passively poll the state regularly (probably in rAF) and look for
>>> changes yourself. Why does it not fire events like "gamepadbuttondown" or
>>> "gamepadaxischange"? This would have a few advantages:
>>>
>>> - it would be consistent with the way all other input events are handled
>>> on the web platform
>>> - it is easier to program for. As it stands since there is nothing like
>>> a "gamepadbuttondown" event, so if you want one, you have to implement it
>>> yourself by polling the state, keeping the previous polled state, and
>>> comparing the differences looking for a previously up but currently down
>>> state and then run your handler.
>>> - browsers have a couple of important features that can only work in a
>>> "user gesture", such as opening a popup window, copying to the clipboard,
>>> or - critically for games! - starting audio (or video) playback on mobile.
>>> Since the Gamepad API does not fire events, this does not integrate nicely
>>> with the existing "user gesture" model, and therefore currently no browser
>>> allows these features to be triggered by gamepad input. Considering the use
>>> case of a gamepad controlling a browser game on a tablet, it's pretty
>>> embarrassing that you can't play audio without resorting to some other kind
>>> of input, like regularly leaning forwards to touch the screen.
>>>
>>> This could involve significant changes to the spec, but I think it's
>>> necessary. It looks a bit like a first draft that never got reconsidered.
>>>
>>> Ashley Gullen
>>> Scirra.com
>>>
>>>
>>>
>>> On 9 April 2015 at 12:52, Arthur Barstow <art.barstow@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> A new Working Draft publication of Gamepad is planned for April 14
>>>> using the following version as the basis:
>>>>
>>>>   <https://w3c.github.io/gamepad/publish/gamepad.html>
>>>>
>>>> If anyone has any major concerns about this, please reply right away.
>>>>
>>>> A few notes about this spec:
>>>>
>>>> * This spec is now using Github <https://github.com/w3c/gamepad> and
>>>> the ED is <https://w3c.github.io/gamepad/gamepad.html>. PRs are
>>>> welcome and encouraged.
>>>>
>>>> * The permissions of the spec's now obsolete Hg repository will be set
>>>> to read-only.
>>>>
>>>> * After Ted copies the open Bugzilla bugs to Github, the spec's
>>>> Bugzilla component will be marked `Historical` and set to read-only.
>>>>
>>>> -Thanks, ArtB
>>>>
>>>>
>>>>
>>>
>>
>