Recent changes to how OUYA works, (SDK updates, Razer buying them out, the new Razer Forge Cortex stuff, and more) have rendered the old OUYA target... a bit broken.
The old controller code no longer works 100% of the time on the new Razer Forge, so I took some time rejigging the target, and making it a bit more compatible.
Along the way, I also got involved with a few other devices (mostly PlayJam's GameStick) and had time to tweak the code so that it seemed to work fairly universally.
After a lot (A LOT!!!) of testing and tweaking and rejigging, I can safely say that this is probably the best that I can personally manage. (But others may fair better)
The new controller code has been tested, and has been shown to work on the following devices.
Archos GamePad 2 - One of those Android tablets with an inbuilt controller.
The code has been shown to work with all standard included gamepads, as well as with my trusty Wired X360 USB pad.
It should (*should*) also work nicely on anything else you'd like to throw at it, but .. This is Android.. It'll be a case by case basis, I'm afraid.
Let me know what does/doesn't work, and I'll add it to the list above.
The code has been approved (ie, has gotten through review) on OUYA, as well as "OUYA for Cortex/Razer" and also by PlayJam for GameStick, and their new FlarePlay device.
PlayJam Flare's Audio Crash
NOTE : If you use any .wav file which are less than 2048bytes (eg taps, menu blips, gunshots) the PlayJam FlarePlay has seemingly random issues with such small files, and your game may crash whilst trying to play them.
I've only seen this on Flare, so far, but .. Android!!
If you have any such files, I suggest you pad them out a bit with some silence at the end, before releasing an Android game into the wild.
(I know this is completely unrelated to the controller stuff, but it baffled both me, and the PlayJam guys for quite a while, with me thinking it was my controller code doing the breaking.. so thought it important to mention!!)
I don't USE the AppStore/IAP stuff, and I appear to have completely fudged it all up.
After upgrading the OUYA SDK, Mark's old "monkeystore.ouya.java" was throwing up a whole bunch of errors, so I did a big old /* Smeg all this!! */ Rem-Block around it, until it ran again.
As such, you will NOT be able to do any IAP or anything like that, until you, or somebody else, bothers to fix it.
Also note that, since this is reliant on the OUYA SDK, it won't even work via GooglePlay or anything else.
Purchases on Android are SO messy, it's unreal!!! So many different markets, and each one with it's own rules.
Freeware's just easier!!
This is laziness on my part, but all my games are free so .... Meh!
Again, not something I've tackled here.
You're going to have to decide how to deal with those, yourself.
I've recently opted to use a "4 dots, one is lit" style of "suggesting" which button to press.
This means there's no having to specifically name the buttons, or anything like that.
It seems to work reasonably well, and unless some stupid company comes up with a controller who's face buttons aren't layed out correctly, it should more or less be universal.
The folder goes to C:\Monkey\targets\
A LOT of stuff has been rejigged to get controller support up and running on so many different devices.
Although, over the course of about 2 months, I was removing, replacing and undo-ing a LOT of my own edits!! As such, it may or may not be as complicated a tweak as I'm remembering! It just took bloomin' ages getting it to this point..
I've kept it as a separate target so that if Mark ever gets around to doing his own OUYA target update, mine won't get in the way.
Code your game, switch to Android_NewYA, job done!*
(*The job is never done!!)
Unfortunately, standard Android devices seem to have issues with Multiple BlueTooth controls, whereby they stutter, struggle and lag like crazy.
This is entirely device dependent and requires stress testing on a per-device basis.
OUYA and Forge don't seem to have any multiplayer issues at all, so I think they're doing other stuff with the controller code, possibly using WiFi to enhance the signal or something?! *shrugs*
If you hardwire a controller (eg Mutliple Wired X360 controllers via a USB Hub) to a "slow" device, it seems to work perfectly fine, so I'm 95% convinced that the "issue" is with Bluetooth itself, and not my god-awful coding.
If you can find a cure for this, be sure to let me know.
Single player is spot-on! (Or at least, it should be!!)
Some controllers work in a way in which the left analogue trigger moves JoyZ(0) and the right one does JoyZ(1)
Some controllers work so that left trigger makes JoyZ(0) go negative, and the right trigger makes JoyZ(0) go positive.
I can't find a safe way to tell which type of controller the player is playing with, and you're just going to have to handle that stuff on your own.
I tend to avoid using them, that's the laziest way!!
I'm not a tidy coder, and my updates are messy.
There are probably many ways to make this code 100* better.
If you wish to complain about my code, I will not listen. My mind automagically blocks "messy code" complaints.
Instead, don't whinge, take up the task for yourself, and see what you can do.
I also, lazily, probably won't be updating this any time soon.. My job here is done, and I'm happy with how it works.. so take it as it is!