Re: Gamepad API

On Thu, Oct 13, 2011 at 9:13 AM, John Villar
<johnvillarzavatti@gmail.com> wrote:
> Hi all, i'm new to this list and was just checking the Gamepad API, it

Hi John,

Thanks for having a look.

> called my attention that there isn't currently support for events based on
> Gamepad Input, and the only considered use case is the continuous polling of
> the gamepad.
> Wouldn't it be good to support an event driven approach too? not all games
> need continous polling, nor continous drawing of the UI (think Nethack).

Yeah, definitely. Ted and I talked have talked about it a bit and I
think Mozilla has some events in their prototype (?). The main problem
is this:

1. The gamepad api shouldn't do deadzones before returning the data to
the game (for a few reasons, see below)
2. Thumbsticks are analog devices, and as such have sampling noise, so
without the deadzones there's a lot of spurious events as the
thumbsticks "wobble" small amounts.

Together, those make an "onchange"-type get fired a lot more often
than expected which might be confusing/expensive.

One possible solution might be to have the user supply deadzones to
the API to control when the onchange's fire. That API gets a bit
complicated. For example, some game controls deadzone axes separately
(say, using up/down thumbstick as a car accelerator), and some should
deadzone treating a pair of axes together as a 2d vector (for
controlling a character's movement). And in that case, maybe it should
be able deadzone 3 axes together too? Not insurmountable api-wise, but
it would definitely add some complexity.

All that said, maybe what we should do for V1 at least is just to have
the minimal "ongamepadchanged" event to offer support for that
programming style. It may be noisy and fire at 60Hz in the worst case,
but would work more naturally for non-requestAnimationFrame-based
games, as you point out. Does that sound OK to people?

> Also, the dead zones are just one scalar value per axis, and i think there
> are (or at least there were, i had one microsoft sidewinder which had a
> tendency to bob to the right) Joysticks that had non-symmetrical dead zones.

Good point. You're referring to the "suggested dead zone" field? I
think generally the deadzone should be a buffer around any asymmetry
so in the case you mention above, it would just have to be larger (and
there'd be some extra dead space on one side) to account for the
off-centre-ness.

> I see this standard proposal as a MUST for games on the web, and it's very
> nice to see there's already a lot of progress :-).

Thanks for your support. :-) Hopefully it'll get into some browsers at
least in a "preview" form soon enough, and then we can work on
smoothing out the rough edges for standardizing.

scott

Received on Friday, 14 October 2011 22:58:11 UTC