>Thanks, but I guess I didn't get across how much I still hate Java. ;)

Can't solve that.. ;) ;)

>I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly).

I suppose you'd have to get a little more particular in the 95% of problems angle. I have been working with Java for quite some time and TyphonRT contains necessary workarounds or API extensions enabling predictable speed. For instance TyphonRT being a Java based component architecture is highly dependent on iteration over collections of components. The custom collections API in TyphonRT has recycled and resetable iterators overcoming the "iterator problem" of the standard collections API. There is a bit more of other things done too to provide predictable runtime performance. A lot of that involves staying as memory efficient as possible and not triggering GC. Of course when things get too hairy yeah native code is used. One has to do that for physics engines (Box2D / Bullet) especially on Android. I'm really loving JavaCPP which is a relatively new effort for managing native bindings (http://code.google.com/p/javacpp/).

>I'm sure your platform will be useful for anyone porting J2SE code to Android, but that's not me.

If you are most familiar with C/C++ certainly by all means go with that and the NDK and use BatteryTech, Proton SDK, or something like that to provide the core cross-platform architecture support.

>And it doesn't look like you're supporting iPhone?

Not yet, but just like Unity which you mention cross-compilation is not out of the question. Like libgdx once the main framework is mostly finalized I'll be looking at say an Angle backed for the desktop and / or other options for expanding device and environment support. The primary goal is to create a leading edge Java framework / platform first. The platform / PaaS aspects also are a priority in the short term among many other things like strong Scala support / integration over say iPhone support. A thing to keep in kind too is that TyphonRT is not just aimed at game dev, but is applicable for all dev efforts including enterprise.

So yes, if you need cross-platform support go native or use a canned 3D engine like Unity if it matches the type of game you are trying to make.

>I know that middleware providers will step in to fill in the gaps, but it's just annoying to be non-native on ALL platforms.

Hrm? C / C++ is available on the majority of platforms... ?

>http://www.batterypoweredgames.com/batterytech is one that I know that's low level, for instance -- it gives you events, OpenGL and sound on Windows, Mac, iPhone, and Android. It's pretty bare-bones, though, as far as I know.

Yes it's not a complete game engine nor is Moai which you mention you have your eye on presently. BatteryTech, libgdx, and TyphonRT provide the core architecture to abstract the common requirements (input, audio, etc.) for real time apps & games. TyphonRT also has higher level optional components for game dev including a fully featured component oriented entity system (libgdx / BatteryTech, etc. don't). This class of tech is meant for folks that can build their own engines and perhaps their own creative games rather than trying to force canned engines to do things they are not great at doing. As mentioned though there are optional components with my efforts to further assist game dev efforts beyond core architecture abstractions.

Regardless of what you choose though I hope you make some cool games for Android! :)