correct, you just need to implement the conroller handling via ouya sdk and thats all
Some post content moved to more appropreate discussion thread here
correct, you just need to implement the conroller handling via ouya sdk and thats all
Some post content moved to more appropreate discussion thread here
Last edited by WILL; 10-06-2013 at 12:54 AM. Reason: Removed off-topic part of post and put in another thread!
Oxygene. You can debug in the IDE right off the device as it runs. Hands down that makes all the difference. To compile for Android you need to make a seperate project from what you would run off your desktop to develop initially. And since the hardware requirements are vastly different for Android devices and of course the OUYA how else could you tell how well it performs or fix any platform/hardware speicifc issues unless you can debug while it's running in the exact environment you will deloy your app on.
Lazarus is great, I love it for desktop development on both Mac and Windows, (and I've had some fairly decent experiences on Linux too) but for mobiles it's not useful enough. You *can* do it, but it doesn't mean tyou *should* do it.
I wouldn't use Lazarus to make games for mobiles, I just wouldn't be able to make them stable and fine tuned enough for what quality I would want to produce games, so I can't suggest that others ignore this as well.
The right tool for the right job afterall.
So in saying that, you want to use Oxygene, especially if you plan on selling your games for profit. And the OUYA "Store" will be a great way for indies to make some money off their work. More so than any other platforms out there. Though Google Play and iTunes App Store are good markets, but more saturated than OUYA's offerings.
I don't think that even Ecplipse can debug on device. Please correct me if I'm wrong, I would sincerely like to know if that's not the case. (Paul and I have even considered, but have not looking ointo Eclipse.)
We have found libGDX to be excellent at this! capturing mouse and touchscreen actions has been very easy as they are treated the same. So you can test on desktop for single finger touch using the mouse. Multi-touch obviously can't be tested off-device, so testing on device is necessary. You won't need to worry about about this on OUYA unless you plan on using the touchpad on the controller.
And there is this great post about using libGDX to receive OUYA gamepad input in your existing apps/games: http://www.badlogicgames.com/wordpress/?p=2733
There are others that may work really well, but Paul and I have had only great experiences with libGDX so I would recommend trying it out. If you guys know of any others post them here!
And lets keep the C/C++ vs. Pascal discussions out of this thread please. This is here to talk about the OUYA and making games (or apps) for it. Thanks!
I made a new thread for you guys to continue your conversation here: http://www.pascalgamedevelopment.com...-vs-C-argument
Here is a link to the FPC Wiki, but I don't know much about the specifics. http://wiki.freepascal.org/FPC_JVM_Android_Development Again, I wouldn't use this tool as I can't debug while it runs on the device using FPC. (Unless there is another tool or someone made a tool.)
IMG_3836.jpg
Testing Subject 33 on an Android device from Oxygene's IDE.
It's a Samsung Nexus S phone in case anyone is curious.
to take advantage of fpc on android you should really forget about JVM or DVM and instead go with pure native code. here is the easiest way that it can be done (this is a fairly new article): http://wiki.freepascal.org/Android
you are wrong. Eclipse can debug the java code on the device out of the box. Put a break point and wait for the program to hit it.Originally Posted by WILL
native code debugging is a bit more complicated but definitely possible. here is an article on how to do the setup for native debugging:
http://mhandroid.wordpress.com/2011/...-cc-debugging/
so what exactly is the advantage of using Oxigene?
I couldn't disagree more. Java bytecode IS native on Android. Which CPU architecture would you support? And what others will you not let run your game? Android was designed to run Java not CPU specific code. If you want to be 100% native you need to generate Java bytecode.
Your suggested method of creating Android apps would leave other speific hardware out in the dark and that's not a good idea considering all the different hardware manufacturers that make Android devices out there. And who is to say that there won't be a change from ARM to x86 or something else?
The idea of only "native code" is the way to go should have went out the window when you decided "hey I'd like to make an Android game/app." Google made this a design choice when they designed the OS.
I can't subscribe to this idea as it's just making extra work to get the "sense" that you are making a better app than taking full advantage of what the Android OS provides as a platform. You shouldn't have to work so hard just to make it fit on a select few devices.
Ok thanks! I was going to look into it eventually, but I hadn't gotten around to it.
Yep and then they had to redo it all with the NDK=) because the "native" java code was way too slow for any performance intensive app. as for different cpu architectures, so far ARM dominates the market of the android devices and even if there will be another cpu in the future recompiling your app for that architecture will just be a minor task. overall considering that you get significantly increased performance by using the true native code, I'd say it is worth the trouble.
Bookmarks