Re: [Gamepad] Liveness of Gamepad objects

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.

(That said, I'm confused--where's the event to tell the user that the
gamepad has changed?  Surely this API doesn't require the developer to
poll, which would lose inputs at the slightest GC skip and could never give
high resolution timing.)

I'd also be very surprised if I received a Gamepad object and its values
were live--the interface looks like a snapshot.

On Tue, Apr 29, 2014 at 9:39 AM, Ted Mielczarek <> wrote:

> snapshots and see what's changed. (Additionally as an implementation
> detail this maps very well to the Windows XInput API, which is a
> polling-based API.)

You can't just map a "gamepad.xButton" property to
"NativeInputAPI.getCurrentXButton()", because you need to guarantee that if
you read the property twice in a row without returning to the event loop
the result is always the same, even if the button state changes while the
script is executing.  You could prevent this by caching the result and
clearing the cache when scripts aren't running, of course.

On Tue, Apr 29, 2014 at 2:27 PM, Florian Bösch <> wrote:

> I think both semantics are workable. I'd likely prefer the gamepad state
> to be immutable from JS, because assigning state there is smelly. I'd also
> prefer the option that incurs less GC overhead if possible. Beyond that, I
> just think the implementations should be semantically and symbolically
> identical.

No, the object should be mutable, since most web API objects have mutable
properties.  If I want to do things like

gamepadState = getGamepads()[0]
// Run the input logic, but pretend the A button isn't pressed:
gamepadState.aButton = false;

then I should be allowed to.  There's nothing strange about this in a JS

Glenn Maynard

Received on Tuesday, 29 April 2014 23:28:58 UTC