Search the Community

As you might have seen a few days ago, I've been trying to work out what is needed to get Phaser working as best as possible on an Ouya using CocoonJS. It has been a very frustrating road and, while I have had some successes, I've also finally hit a point where I really want some other people's opinions on where to go next. First, though, some solutions. So, as it turns out, I was only partially right in the additional property to test for in my change to the "pollStatus" code for gamepad input. It actually needs to test for the property and call the function too. Here is the code for that. var rawGamepads = (navigator.webkitGetGamepads && navigator.webkitGetGamepads()) || navigator.webkitGamepads || (navigator.getGamepads && navigator.getGamepads());(This has the added benefit of working in Firefox Aurora too now, but more on that a little later in this post.) Through my testing, I was at first surprised and then highly annoyed to learn that the 'index' property of gamepads in CocoonJS is unreliable. While the specification states indices start at zero, it doesn't include how counting should happen between gamepads being connected, disconnected, or reconnected. The result of this is inconsistency is that, in CocoonJS anyway, you might get "0, 1, 2" for the first three controller indices, or you might get "0, 5, 8" sometimes. (It also doesn't help that the CocoonJS Custom Loader remembers the last index as long as it is running. I was up to an index of 25 at one point yesterday.) To combat this issue, and hopefully not break the existing Phaser code for other systems, I have the following patch for "ongamepadconnect." this._ongamepadconnected = function(event) { var newPad = event.gamepad; _this._rawPads.push(newPad); for (var i in _this._gamepads) { if (!_this._gamepads[i].connected) { _this._gamepads[i].connect(newPad); break; } } };Instead of trusting the index of the gamepad, it looks for the first open slot within the four gamepads (as of 1.1.5 in Phaser) and 'connects' it. If all are connected, "_gamepads" is not updated. And here is the patch for "ongamepaddisconnected" too. this._ongamepaddisconnected = function(event) { var removedPad = event.gamepad; var removedPadIndex = 0; for (var i in _this._rawPads) { if (_this._rawPads[i].index === removedPad.index) { _this._rawPads.splice(i,1); removedPadIndex = i; } } _this._gamepads[removedPadIndex].disconnect(); };This time, instead of removing according to the "removePad.index" (as was previously the case), it finds the index of the pad to remove from "_rawPads" and uses that. Because I wanted to test the above code on another system, I turned to running in Aurora (since I knew it supported the two events). This became a very Good News / Bad News situation. Good News: Aurora passes the same "(navigator.getGamepads && navigator.getGamepads())" test CocoonJS does. No changes there. And there is now a new 'connected' property per gamepad built in too. Bad News: Gamepads no longer have a 'timestamp' property and buttons are now "GamepadButton" objects. The former is a fairly easy fix. Test if the index of the button array is an object and then look for its 'value' (float) or 'pressed' (boolean) property. The later is more complicated, and a problem I've recently learned CocoonJS suffers from too. (After the Aurora testing, I used the same code on my Ouya in CocoonJS. It has a 'timestamp' per gamepad, it turns out, but it remained a '0' during all of my testing. Not helpful. At all.) All of this explanation and code now brings me to some questions: Should the Phaser code be re-written to match these two systems? And if so, what is the best way to go about it?It should be possible to use "this.game.time.now" to record our own timestamps. And I think this could even happen as part of "pollStatus" function somehow. But I really want some second, third, and maybe even fourth opinions about how to go about it, or if it should even be done in the first place. After all, the Aurora and CocoonJS timestamp issues might work themselves out in their next versions. Or they may not. I don't know if it is worth waiting several weeks at a minimum to find out. Is there anyone out there willing to either work with me or independently collaborate on this Phaser + CocoonJS debugging?I'm making progress in fits and starts. And I know other people are waiting for the go-ahead to start using Phaser in CocoonJS without problems. I figure there has to be at least one other developer willing to just check over that "Yes, this works for me too" or "Nope, I don't see that here" on these various changes. While I was thrilled @rich was willing to adopt my earlier changes, it has made me more skittish the deeper I go and the more little bits of code I change to get Phaser working in CocoonJS as smoothy as possible.