Lets talk OUYA

[WILL]

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.

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.

[Dan]

Google made this a design choice when they designed the OS.

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.

[Daikrys]

have to agree that true native code will run alot faster, for example my games made with zengl run really good on my superpad 2 (which is a cheap chinese made pad) and the java games run very poor even if simple made

Dan's game also runs smooth enough to play, which is true native code?

[WILL]

I would tend to agree with you guys on the principle, however that's just the way the OS was designed.

On the note of Java being slow, I should point out that originally I was dead against it for making games having experienced it long ago in my own attempts to learn it's language. Times since then have certainly changed however and taking full advantage of OpenGL/OpenGL ES has seemed to help it a lot. All apps on all your Android phones are a testament to how improved performance has been in Java bytecode. Minecraft is another example of efficient and fast Java. (considering all the data and chunks of network data it has to deal with)

I think that the idea that Java is too slow for games is an old idea and if the VM that runs it is fast, so too will be the game/app that it runs on. Case in point Another World is written in interpreted code and it ran extremely well on old DOS and Amiga computers.

A lot of technology that we used to think just stunk has seemed to have gotten a lot better over that last 10 years.

[Darkhog]

Yeah, but still native code will be faster than bytecode.

Also Java's slow. It is faster than it was earlier, but still is slow.

Case in point: Blockscape, which is minecraft-inspired game with MUCH higher level of detail and written in C# is much faster than Minecraft for most players (Minecraft's FPS:17-25 at max, Blockscape's: 60-120). Both are bytecode, and yet C# is faster there.

Anyway, I believe native version would be even faster than that. I think we should lobby Ouya makers to allow native apps (if it doesn't already).

[SilverWarior]

Case in point: Blockscape, which is minecraft-inspired game with MUCH higher level of detail and written in C# is much faster than Minecraft for most players (Minecraft's FPS:17-25 at max, Blockscape's: 60-120). Both are bytecode, and yet C# is faster there.

You do know that Minecraft graphical engine is not the best one. Yes it has improved quite a bit in past years but still not enough. But there was a HD graphics mod for Minecraft which actually raised Minecraft FPS way abouve 60 and this on almost every computer with decent graphics card.

Another problem in Minecraft is that its core is quite porly written and can lead to lower FPS. You can clearly see this by the fact that you are getting way higher FPS and much lower CPU utilization when playing Multiplayr in comparison of playing Singleplayer game. And yes Minecraft performance went down again quite a bit in newer versions.
Now several mod packs like Technic Pack and such actually change part of default Minecraft code to make it much faster. Notch doesn't put much on optimization.

So using comparison of Minecraft with Blockscape to determine wheter JAVA is so much slower than native code is not best idea.
Best idea would be to write some benchmarking tests for true comparison.

[WILL]

So using comparison of Minecraft with Blockscape to determine wheter JAVA is so much slower than native code is not best idea.
Best idea would be to write some benchmarking tests for true comparison.

Ok maybe not the best example, but considering how much the guy made off of that game sold at a reduced price with a free and/or demo version to try first, it does prove that Java isn't so unusable for games.

Anyway, I believe native version would be even faster than that. I think we should lobby Ouya makers to allow native apps (if it doesn't already).

I've seen some OUYA games so far and they play beautifully. So I seriously doubt that "the slowness of java" is such an issue as you guys make it out to be. It's not like the console is running a super low-end CPU either.

I believe that your slow issues will be in your graphics implementation and processing.