Update: Within minutes of me posting this, I received more information about the Gamepad API in CocoonJS. It is now confirmed, as of this writing, that gamepad index values always increase after disconnection events and that the ‘timestamp’ property is always ‘0’. No word yet on the axis out-of-range values.
I have been spending several hours a day for the last few days testing and documenting the Gamepad API in CocoonJS on the Ouya. It started with my realization that the ‘index’ and ‘timestamp’ properties were unreliable, and has now expanded into issues with axis values and my pursuit to incorporate a radial deadzone algorithm. This latest journey, though, started yesterday morning.
In my research, I came across this post detailing how to create a radial deadzone. It was something I didn’t realize I needed to implement myself until I saw the description of “as you rotate the stick across one of the cardinal directions . . . you’ll feel it ‘snap’ to the cardinal [direction]” in relation to a “naïve” way to use deadzone values. It was something I had noticed in my own code too, the ‘snap’ of gamepad axis values as they moved out of the deadzones and started reporting values.
Then, after even more time debugging my code line by line and testing every value calculated and used, I discovered something very… strange. The algorithm would be working perfectly in Firefox Aurora. I was getting a very smooth transition across each axis. However, when I used it in CocoonJS on the Ouya, the numbers were still very large. Numbers, again, that should not show up.
This lead me to comment out my newer code and do a simple fixed-rate polling dump of each gamepad connected to the system and its current axis values. This revealed the problem, and a major bug in CocoonJS on the Ouya. When at rest, the first connected gamepad’s axes and axes would report large numbers. Instead of some very small, close to zero values, it would produce numbers outside the range of -1 to 1. It’s a problem, as I took pictures with my phone to show, that affects the Ouya, PS3, and Xbox 360 gamepads. Whatever is considered the first paired gamepad at the time.
(Note: settings.LEFTAXISTHRESHOLD is 0.265 and settings.RIGHTAXISTHRESHOLD is 0.239. Numbers pulled from the recommended XInput deadzone values.)
- As I mention at the bottom of the post here, if you contribute to any libraries that use the W3C Gamepad specification, you should consider testing for the GamepadButton interface object and its ‘value’ (double) and ‘pressed’ (boolean) properties soon. Firefox Aurora already uses it and it will properly ship in Firefox proper within the next couple months. At that point, or probably sooner I imagine, Chrome will change its API too to match.
- Firefox Aurora and current CocoonJS either do not have or incorrectly report the ‘timestamp’ property. I’ve already started preparing fixed-rate polling code for the possibility of a coming future without that property as part of gamepad objects. (This, despite it remaining in the Working Draft copy of the specification.) If you work on HTML5 libraries or projects using the Gamepad API, it might be time to start thinking about doing so too.