Writing Custom Firmware

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:
http://randomfoo.net/2013/05/10/hacking-the-ouya

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.

3) Operators
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;

Instead of:
d.Add(a);
d.Add(b);
d.Add(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.

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

Comments

  • Killa_MaakiKilla_Maaki Posts: 504Member
    edited July 2013
    I don't think using Java for games is as big a deal as you make it out to be. Used to be, the gap between managed languages and native languages was huge. Not anymore, even on mobile.

    Basically, making a game run at 60+ FPS on Android is no big secret, nor even very difficult. 99% of the optimizations are graphics optimizations (not using so much fillrate, reducing draw calls, etc). The other 1% is not constantly allocating memory. Yes, the garbage collector happens whenever it wants to, and the only direct control we get is basically "hinting" that we want garbage collected now rather than later. But that's really easy to work around, just store things in temp variables or implement pooling structures and you're good to go.

    And if you can make a game run at 60FPS, does anything else matter? No, it doesn't.

    I applaud the effort, but I don't think the problems you're attempting to solve are big enough to matter. Additionally, one really big benefit of going with Android over, say, a custom Linux build, is that there are a much wider variety of existing game engines supporting Android than there are Linux (mobile games are the hot new thing for big game engines to support right now). If it were a custom Linux build, I doubt I would be able to use the Unity engine on it, and if I couldn't do that, I don't think I would be developing for it at all.
    Post edited by Killa_Maaki on
    You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
  • pietasterpietaster Posts: 69Member
    edited July 2013
    I think its just the point that we at least want the option of unlocking the bootloader and changing the OS. Not unlocking it isn't giving us the options that was said we would have when we pledged the money. If you're confined to Ouya OS and you had expectations of using something else, you do not have this option. I think this is the point many are making. If you guys have no need for anything other than Android/Ouya OS than that doesn't mean everyone will feel the same way. 
    Post edited by pietaster on
  • Killa_MaakiKilla_Maaki Posts: 504Member

    pietaster said:
    I think its just the point that we at least want the option of unlocking the bootloader and changing the OS. Not unlocking it isn't giving us the options that was said we would have when we pledged the money. If you're confined to Ouya OS and you had expectations of using something else, you do not have this option. I think this is the point many are making. If you guys have no need for anything other than Android/Ouya OS than that doesn't mean everyone will feel the same way. 
    I have nothing against writing custom firmware in general. Sometimes it results in cool projects (REALLY cool projects). But it's a little strange to write custom firmware that tries to solve nonexistent problems.
    You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
  • pietasterpietaster Posts: 69Member
    edited July 2013
    I have nothing against writing custom firmware in general. Sometimes it results in cool projects (REALLY cool projects). But it's a little strange to write custom firmware that tries to solve nonexistent problems.
    No I agree with you there I mean have a couple of really good reasons for doing what you're doing and think them through. But still the option should still be there I think. Its not right to call hardware open when an OS is forced upon everyone with no way to make modifications.
    Post edited by pietaster on
  • cippyboycippyboy Posts: 6Member
    edited July 2013
    @Killa_Maaki

    I don't know what kind of game you developed so far but let me summarize java game development on Android :
    1) Canvas drawing is ~10 times slower than OpenGL, I used to have only 20FPS with less than 20 32x32 pixel sprites. That was awful, once I used GL, I got constant 60 FPS even with 30+ sprites.
    2) OpenGL on Java needs bytes inverted cause Java is Big Endian even though ARM is little endian. Pretty cool to reverse all your vertex buffers's data, right ? That most certainly won't cause unneeded allocations or garbage collections.
    3) Java performance is good unless you do something that requires more logic. I needed to make a backtracking algorithm for one of my games, and took ~5-10s to backtrack and array of 13 numbers with a value of 0-5 each, and yes all data was preallocated. Once I turned the java code to C++ (which was pretty straight forward), the algorithm feels extremely instant, I'd say under 0.5S, so there you go 10X speed boost for just using C++.
    4) Quitting an activity does not mean releasing all it's memory, or rather onDestroy doesn't destroy the app process, so you can have scenarios where during onCreate you can be left out of RAM. Why ? Because you probably stored something in a static variable. Why do that ? Because you probably want to share data between activities without reloading everything for each new activity. Why have more than 1 activity ? Well I dunno, share to facebook, online leaderboards, third party ads (when they will exist).

    To me I think the initiative should be led by the OUYA devs to make a special Android distribution where they can easily design the UI with Android widgets if they think that saves development time but give us a different development environment where we don't have to rely on Activities. Seriously now, if someone wants to share some image to facebook or twitter without the respective (Java) SDKs, there's a small chance that starting a new activity will close the game activity which is a very poor user experience for a game.

    Second point is debugging with the NDK. I tried to debug C++ code for Android with 2 or 3 devices and it fails for random reasons cause I don't have the device/ Android version that the tutorial I'm following has, cause Android has a ton of specific device issues, so yeah, an environment that lets me debug the thing I'm coding with breakpoints and watches kind of like Xcode/iOS would be great.
    Post edited by cippyboy on
  • Killa_MaakiKilla_Maaki Posts: 504Member
    Ah, I suppose I must say I'm not using Java :P
    I happen to be using Unity, which appears to have basically solved everything you're having trouble with. Although debugging is still a PITA, not due to Android but just because of Unity in general (Unity's debugging sucks even on PC, you basically just get the ability to log messages and that's it)

    I'm fairly certain Unity uses NDK to implement the Unity Engine, and then basically runs your game on top of that. Most of my game script (probably 99%) is in C# (which is actually really similar to Java, language wise). This is compiled to an intermediate bytecode and executed in a virtual machine in Mono. I've found it so far to be highly performant, even for more complex game logic.

    So I'll say this. It sounds like what you have issues with are Java, but not so much Android itself. Debugging is an issue, but until you fully figure it out you could do what I am doing - logging information, and reading it via logcat.
    You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
  • TRUEtravTRUEtrav Posts: 57Member
    That's one thing I've definitely noticed too: many use Unity to develop their games. Games like ShadowGun do prove that it runs quickly enough, but again, Unity's not the best answer for everyone. Also, all game logic written in Unity is all scripting language and interpreted on-the-fly as well. That's been my experience, anyway.

    I've seen a lot of reviews online saying that the Tegra 3 is aging hardware because the OUYA was released right before the Tegra 4 comes out and that this $99 console's hardware can't compare to XBox 360/PS3. True, it won't go toe-to-toe with a 360, and not expected to perform to those consoles' standards, but the gap could be closed a bit with a game-centered OS that's not geared to make "apps" that people will only use casually for a few minutes' time. The OUYA isn't just a console, it's mobile hardware used specifically in the context of games, and so it's especially necessary to cater to that. TVs don't run on Android-Linux, at least not yet, they run on stripped-down Linux-based OS's designed with that specific hardware in mind.

    The OUYA comes with 8GB of internal storage in yet, nearly 1GB of that space is required just to store the OS? Why? The PSP's Linux-based OS had like maybe 32MB (maybe 64MB) of internal flash just for the software and only used like 8MB of kernel-space RAM.

    Other reviews that point out how there's still phone-specific features lurking in the settings like GPS which isn't necessary or accurate for a stationary console hooked up to wi-fi. Seems a bit weird that we'd have GPS on a day-one release, but not dedicated a matchmaking service, leaderboards, etc which will come later. Not that it'd be difficult to implement at least leaderboards ourselves, but still.

    I think the OUYA's hardware has more potential than the software will allow, and any 'efficient' workarounds are a major pain and possibly expensive (NDK + JNI, lol). If the company does plan on releasing a more powerful console every year, then it seems like they'd be taking a step forward, and part of a step back if they keep using non-game-friendly software. I'm not saying specs make games enjoyable, but it seems like it is possible to get noticeably better-looking games for the same without needing more expensive hardware. Again, it's a matter of who and how many at OUYA has the skills and time to build a mobile Linux distro if they wanted to. Mobile OS development also intrigues me, I think and the OUYA already provides the perfect set of hardware to me (System on a Chip, wi-fi, bluetooth, flash storage, controllers, etc) to start working on it.
Sign In or Register to comment.