Re: [w3c/gamepad] Should fire events instead of using passive model (#4)

One thing that might make this slightly awkward for the common use case in games is that AIUI most game loops have a process input / update state phase and a render phase. Currently most JS code I've seen just mashes those both into an rAF callback, handling input and updating state first, then rendering. Presumably the slightly better option would be "run a setInterval callback at a fixed rate to do input handling/state updates, do rendering in rAF", but I don't think that matters much for the purposes of this discussion. The Gamepad API currently provides `getGamepads()` to poll for immediate state, which matches the expectations of game programmers given the APIs available on other platforms. If we add events, then users will have to manually track state between event handler callbacks and the input handling phase. Maybe this isn't so bad, someone like @antumbral can chime in.

Some notes on native platform APIs:
XInput's main API is [`XInputGetState `](https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinputgetstate(v=vs.85).aspx), which polls the state of a gamepad, and apparently this is similar to the API provided by other consoles. SDL is a little odd in that it does provide events like [`SDL_ControllerButtonEvent`](https://wiki.libsdl.org/SDL_ControllerButtonEvent), but it does also provide direct APIs like [`SDL_GameControllerGetButton`](https://wiki.libsdl.org/SDL_GameControllerGetButton), and the event loop needs to be manually run by the application anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/4#issuecomment-355329786