On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard <glenn@zewt.org> wrote: > (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.) > This is slightly off topic, but worth addressing. The spec does not, in fact, have any change notifications. Firefox has some experimental ones you can enable but they're not official. This does indeed provide an opportunity for input loss, but I'm not aware of anyone who's actually found it to be a problem. (Given the sparse number of apps using the API, though, that doesn't say much.) This is good feedback, though. It may be that snapshot + change events is the most effective way to go? > 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; > checkInput(gamepadState); > > then I should be allowed to. There's nothing strange about this in a JS > API. > No complaints here. A good use-case for mutable properties may be a JS script that intercepts gamepad snapshots and re-maps them in-place to a standard mapping if the browser has not already done so.
Received on Tuesday, 29 April 2014 23:42:42 UTC