The ouya appears to be ARM based. After setting up my adb interface, i pushed one of our titles over to Ouya directly from Visual Studio 2010 using the MonoDroid runtime. Now we just need the Ouya intents in MonoDroid and then the game should be recognized by the Ouya runtime. Whether it runs or not depends on the GL driver support in the MonoDroid runtime shim. Let's hope that the folks at Xamarin got ahold of a device. Without the Ouya intents, though, there's no way to run the game using the controller.
This should make your manifest file have the correct intent for the Ouya game console. It doesn't show up for me yet, but this is only 4 hours into having an actual device.
Looks like the Xamarin MonoDroid adds a default provider to bootstrap their runtime into the loading of the MonoDroid target. Not sure what else would prevent the MonoDroid targets from being discovered by Ouya. I don't see the Activity class being overridden by the Ouya framework anywhere. Looks like we might need a special Xamarin MonoDroidForOuya build.
Looks like the Xamarin MonoDroid adds a default provider to bootstrap their runtime into the loading of the MonoDroid target. Not sure what else would prevent the MonoDroid targets from being discovered by Ouya. I don't see the Activity class being overridden by the Ouya framework anywhere. Looks like we might need a special Xamarin MonoDroidForOuya build.
Interesting. Thanks for doing the groundwork here. I wonder how Unity is doing it since it's presumably using MonoDroid for deployment.
I'm sure you've probably tried this already, but just in case you haven't..
The "All in one" thread for Unity has one of our fellow users encountering what seems like the same issue you're having. That was resolved by updating the driver and ensuring the target android version was set correctly on their project. Unity thread Driver
I'm hoping to have some time this weekend to get my monodroid license up and running and insist in the investigation. But if you haven't tried this already, maybe you can give that a shot.
If you don't specify ActionMain and CategoryLauncher in addition to the OUYA intent, MfA will create a second intent-filter node in the manifest and the OUYA Launcher will not see the OUYA intent.
I'm working on the ODK bindings now (they're not necessary to get a game up and running though) and will add the bindings project and an OUYA project template to GitHub soon.
I'm pretty much not understanding anything in this thread haha, but I have made an XNA C# game in Visual Studio, nothing to do with monogame as far as I know, so....
I'm pretty much not understanding anything in this thread haha, but I have made an XNA C# game in Visual Studio, nothing to do with monogame as far as I know, so....
What do I do? X3
Firstly you would need to purchase Mono for Android from Xamarin. This provides C# for Android development. Next you will need MonoGame. This provides a XNA-compatible API that works on Android (among many other platforms). Now you can take your code and data from your XNA game and use it with MonoGame to get it running on Android. Here is a Youtube tutorial on converting an existing XNA project to MonoGame.
Mono? really? i really, really want to see this C# game running on Ouya: http://www.youtube.com/watch?v=kRX5QjWk-w4 (see the video, i think you all want this as well! ) - if people can record and share a video of it running on an Ouya, and a binary package of it for people trying, please do! :)
That would be an interesting test. The project would have to be updated from XNA 3.1 to 4.0 first (the hard bit), then ported over to MonoGame (the easy bit).
Ok, I've got Mazer Mayhem ported to XNA 4.0 on PC. Now to get it over to an OUYA project. But that will be a job for tomorrow night as it is way past pumpkin time here.
Headzup
Posts: 2Member
Comments
At first glance it seems so. We're working on porting MonoGame over to it.
[IntentFilter(new[] { Intent.ActionMain }, Categories = new[] { "ouya.intent.category.GAME" })]
This should make your manifest file have the correct intent for the Ouya game console. It doesn't show up for me yet, but this is only 4 hours into having an actual device.
Use “ouya.intent.category.GAME” or “ouya.intent.category.APP”.
This is the value you use in the IntentFilter above. For MonoGame, you will just use the ".GAME" version of the category.
The expected file is in res/drawable-xhdpi/ouya_icon.png and the image size must be 732x412 for games or 412x412 for apps.
maybe I need to create this "ouya_icon.png" file in addition to setting the launcher icon ... reminds me of xbox development.
The "All in one" thread for Unity has one of our fellow users encountering what seems like the same issue you're having. That was resolved by updating the driver and ensuring the target android version was set correctly on their project.
Unity thread
Driver
I'm hoping to have some time this weekend to get my monodroid license up and running and insist in the investigation. But if you haven't tried this already, maybe you can give that a shot.
http://www.flickr.com/photos/sickheadgames/8346738651/in/photostream/
Should have the bindings and a Visual Studio template in the MonoGame repo in the next few days.
[IntentFilter(new[] { Intent.ActionMain }
, Categories = new[] { Intent.CategoryLauncher, "ouya.intent.category.GAME" })]
If you don't specify ActionMain and CategoryLauncher in addition to the OUYA intent, MfA will create a second intent-filter node in the manifest and the OUYA Launcher will not see the OUYA intent.
I'm working on the ODK bindings now (they're not necessary to get a game up and running though) and will add the bindings project and an OUYA project template to GitHub soon.