Lets talk OUYA

**Darkhog** · 07-06-2013, 11:40 AM

In any case, how one would compile Pascal game for Ouya e.g. from Lazarus or even directly FPC?

**Dan** · 07-06-2013, 04:33 PM

as far as I can tell it's just the same as compiling for an android phone/tab (arm-linux), since tegra 3 is a quad-core ARM processor. I should have some fun with that as soon as I have the console.

**Daikrys** · 09-06-2013, 09:03 AM

Originally Posted by Dan

as far as I can tell it's just the same as compiling for an android phone/tab (arm-linux), since tegra 3 is a quad-core ARM processor. I should have some fun with that as soon as I have the console.

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

**WILL** · 10-06-2013, 12:35 AM

Originally Posted by Daikrys

correct, you just need to implement the conroller handling via ouya sdk and thats all

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!

**WILL** · 10-06-2013, 12:40 AM

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

**WILL** · 10-06-2013, 12:56 AM

Originally Posted by Darkhog

In any case, how one would compile Pascal game for Ouya e.g. from Lazarus or even directly FPC?

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.)

**WILL** · 10-06-2013, 03:09 AM

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.

**WILL** · 10-06-2013, 03:56 AM

The developers of libGDX and Spine showing off some details on using libGDX with the OUYA.

It's a Dev Kit version that was sent out to backers who were willing to pay $1337 USD for one. So it doesn't look as nice as the final one. (More bare-bones.)

**Dan** · 10-06-2013, 04:51 AM

Originally Posted by WILL

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.)

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

Originally Posted by WILL

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.

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.

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?

**WILL** · 10-06-2013, 10:53 AM

Originally Posted by Dan

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

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.

Originally Posted by Dan

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.

Ok thanks! I was going to look into it eventually, but I hadn't gotten around to it.