I've been wanting to write my own Linux-based OS for embedded systems for a while now. With the OUYA coming out, I thought it'd be the perfect platform to start working on. The problem is that this post I found suggests that the OUYA isn't as hackable as I thought it'd be:
It looks like overwriting the OS with something different can easily brick the OUYA, but having security on the bootloader will keep us from the level of modification some of us would like to be. Is this here to keep people from trying to hack the store? If this is the case, then I understand, but since the kernel's open source, couldn't this be possible as-is?
Here's why I want to write my own OS for OUYA:
I get that the console is built from mobile hardware running a modified mobile (aka, embedded) operating system, but I'm not sure if Android is the best way to go. Android focuses on Java development, and running native code in C/C++ isn't supported well. Native games cannot exist without expensive JNI calls to the Java-based ODK, and I think this could be one of the reasons why reading controller input takes such a performance hit.
There are a few reasons I favor C/C++ over Java:
1) Garbage Collector
Java is great for Rapid Application Development (RAD) where users want to build apps which utilizes Android's GUI elements. Garbage collection is part of the design, which although not quite as efficient in all cases, it gets the job done well enough for these types of apps. This would be fine for apps like Facebook, Spotify, a Calculator, etc. but not so much for games. Allocating and deallocating memory are expensive operations, and Java doesn't give the programmer much freedom over the when and where in the code we can do this.
2) Stack vs Heap Allocation
It seems that complex datatypes (object variables, or instances) must always be allocated on the heap, and never the stack. Allocating on the heap means that if you have a method that needs to have some temporary storage instances of your Vector and Matrix classes, you'll have to allocate it in memory each time the method is called, then leave it up to the garbage collector to free later on... whenever it wants... Imagine having to perform CPU skinning that might require some temporary variables, well, you'd be running that skinning method per object per frame. Let's say there's 100 objects in the scene and you shoot for 60 frames per second. That method is called 6000 times which means that each instance in that method is re-created and constructed 6000 times a second.
In native C/C++, anything allocated on the stack is allocated when the game is initially loaded, and all that happens when the skinning method is called, all instances are just constructed. The data is all released once as well automatically once the game or that thread terminates.
Constant allocation/deallocation adds a small bit of overhead with each occurrence which will lead your CPU's performance to a death of 1000 cuts, or in this case 6000 alloc's, constructs, and (usually) untimely deallocs whenever the garbage collector thinks it's enough.
I understand that Java code can execute as fast as native code due to how Android works making it feasible on embedded devices, but its memory management will cause a performance hit. Heavy arithmetic on complex, user-defined datatypes will cause this, and this is probably why Google only recommends using the NDK for "physics simulations" and the like. Game programming is full of math like this.
If we had to choose solely between C or C++, there's no doubt many will go with C. It's fast --and many even say it's beautiful. C++, on the other hand, is object-oriented, and due to this, has operators. How nice would it be to have a complete math library written up (I have one, actually), and all of your Vector, Matrix and Quaternion classes have overloaded operators instead of function calls to perform vector-vector, vector-scalar, etc arithmetic. It's cleaner to write this in C++:
Vector d = a + b + c;
Or something similar.
4) Expensive JNI Calls
The entire ODK is written in Java, so if you want to use the NDK for your entire game, then you'd have to poll for controller input from the ODK, you'd have to write the code in Java, then use JNI to pass it to the NDK. Doing this just once per player per frame can be quite heavy, and it'll make the code somewhat ugly to work with. It looks like even working in Java, reading controller input can cause performance issues.
I'm aware that the ODK has more APIs than just the controller, such as required store APIs calls, but the controller APIs are what's going to be called frequently regardless. This is why I single out the controller APIs here.
5) Preference and Current Support
I must admit, I'm more experienced in C/C++ than I am with Java. In fact, I started playing around with Java just to develop on the OUYA. This is where I started noticing how the way Java is designed could affect gaming performance. That being said, there are probably many developers out there that already have a large code base/engine written in C/C++. I actually do, and it's designed to be multi-platform.
Again, this is an embedded system running on mobile hardware where CPU performance doesn't even compete with current-gen consoles (8-year old hardware) quite yet, let alone high-end gamer PCs. That being said, Java wouldn't be a good primary language for a device geared directly towards video games where performance is a huge deal. There's another discussion on some other forums about this topic:
I'd also like to develop my own skills in designing and implementing embedded firmware. I think that the OUYA's current hardware is a great starting point, especially for it's price, but according to that post above
, I may end up bricking my console than hitting breakthroughs.
I think developing custom firmware on the console would be a neat project, promote its "hackability", and promote community support from outsiders. I'd love to write my own GUI system with a 3D backgrounds like you'd see with Mac OS X's Time Machine app, 3D icons, folders, etc. More importantly, I'd like to write a lean OS that only focuses on OUYA's hardware profile that could rival the firmware specs of the PSP (firmware only ate up a few MB of memory).