To enable richer game development, we should expose USB joystick events to HTML. This would apparently be enough to support the top gamepads/controllers on the PC.
(note: there's an existing feature request for this as bug 51800 but it's a bit specific in terms of its implementation suggestions and has ventured a bit into other unrelated features. feel free to dup as you see fit)
I'm running Chrome "18.0.1004.0 canary" on Windows 7 and I'm plugging in a Logitech RumblePad 2 USB. Nothing appears in navigator.webkitGamepads. It seems to be a special list with four slots. All of the slots remain undefined after plugging in the gamepad. I am able to verify with a separate app that the gamepad works.
I got my Rumblepad working by using the Xbox 360 Emulation profile in Pinnacle Game Profiler.
Button8 as labelled in the html-page does not work. The broken button is labelled 9 on the physical thing, and I have verified with Logitech Profiler that the button should be working. Buttons 7 and 9 (physical 8 and 10) seem to work perfectly.
Also, the axisses do not go exactly from -1 to 1, but have some rounding errors in them, so some of them go a bit under or over. Also the middle position is not exactly 0. Not sure if this is a problem.
Everything else seems to work OK.
I'm working on a HTML5 version of DDR (Dance Dance Revolution), and I'd like to use the Gamepad API to get input from real DDR pads (instead of the keyboard).
The DDR step scoring system (linked below) needs to decide whether a button press is within 15ms of the song beat, and I don't think the 16.6ms resolution given by requestAnimationFrame would do the trick. Any chance we can get some button press events with timing information?
Thank you very much!
DDR timing: http://www.ddrfreak.com/phpBB2/viewtopic.php?t=132451&sid=af54dcbbdc1ab6810ceb140734e6956c
I hit a similar issue with pen input -- pen pressure and position information requires more than 60hz for high fidelity. I encourage the module authors to consider this in tandem. It's a very similar technical issue an will present a similar abstract problem solving technique.
Input event timestamps are a good idea.
There is a timestamp field on the gamepad input, but it isn't very high resolution currently. That should be "upgraded" once we have a high-resolution timestamp that we can use across the whole browser. (see also issue #95738).
Additionally, because the main Gamepad API is polling based, it's possible that some inputs would be missed if they were read in rAF. The spec currently talks about an event-based model (i.e. "ongamepadchanged") but it hasn't been fully spec'd nor implemented. It seems like DDR would require that too.
Further complications:
- XInput on Windows is polling-based at the API level, so the accuracy of those timestamps may be limited any way in some cases.
- Chromium does not yet support DirectInput for legacy gamepad-ish devices (issue #110013), which I guess that a DDR pad probably would be. In theory XInput supports them too, but I'm not sure what device+driver availability is like.
@costan: if your game, or a representative timing test is available publically, it would be valuable to see how it "feels" with the API that's available currently.
When Wacom plugged into Adobe Air for their pen events, they used a "penpressurechanged" event. That works pretty well. The alternative is to maintain a queue with timestamps, essentially a large block of binary data. That's done with some resource constrained devices; the scripting environment is passed an array buffer to work with, and the next queue builds at that point. I don't think that route is necessary. That one is super-high fidelity, and I don't have a use case for it. I just need high fidelity. penpressurechanged seems to work on that end. The author then buffers the events in their own array, and processes it during their rAF loop. PS: Please let me know if you're willing to work with Wacom to add pen pressure support. They've repeatedly reached out. It'd benefit Chrome OS.
@scott: I will deploy the demo somewhere you can access it tonight.
I can use my DDR pad right now in Chrome on OSX! I'll try Linux tonight, and Windows as soon as I can find a Windows box.
As far as I know, USB controllers all work based on polling, so driver-supplied USB events have 1ms accuracy. I'd like that 1ms accuracy built into the browser, instead of me having to run a JavaScript loop that runs every ms, asides from the RAF loop that I'm already running.
Sorry, I got preempted.
DDR demo: http://ddr-web.heroku.com
Source code: https://github.com/pwnall/ddr
The animations use SVG, not canvas, which works fairly well on OSX, but is a bit choppy on Linux.
I hope this helps!
