I wanted to make a small poll on the changes i'm about to make with both android orx port.
1) drop android-native port
android-native port require to runs on Android 2.3+ and use the NativeActivty to implement orx main loop.
Since it allow ones to write a complete android application in c/c++, I was expecting to have better performance than with a more traditional jni binding Activity.
Well, the various test i made proved me wrong. There is no measurable performance differences between both orx ports.
That was for the "pro" for android-native.
For the cons, I have one major, the impossibility to use the orx view in a layout (say you want to show an Admob banner, on top of orx). That is just not possible by design.
So, since there is no obvious advantages of using this port, I'm about to drop support for this (code will probably stay in the repo for a while in the repository, but I won't update it / maintain it anymore)
supporting two ports is a bit too much of works for me alone, so the non-native port will become the one and only orx port.
2) raise min API level for the non-native android port to 2.3
the non-native port of orx allowed me to lower the min API level down to 2.1 (not without some issues)
today, android 2.1 + android 2.2 is about 10% of the android landscape see Android Dashboard
thoses are mainly low-end devices old of about 2 years, and wont fit for orx games because of the low specs anyway.
raising the min API level to 2.3 will allow me to implement a better Sound plugin by using OpenSL ES, simplify file I/O and some other stuffs.
So I'd like to hear you opinion / question on theses changes before doing anything...
Just to make sure, there's no differences from a user point of view between using the android and android-native versions?
What I mean is, if I want to use the non-native android version, I won't have to write any java code, will I?
that's the required minimal Java code you need to write
take a look at demo/android project, it's very light
I'll try to remove the requirement to call enableAccelerometer(), and the need to override requireDepthBuffer() if you need an OpenGL depth buffer
I would also bump up reqs to 2.3+ since this would be for gaming. But I am a bit more hesitant about that part. Perhaps other people who are interested in deploying to Android can pitch in?
bitbucket repository has been updated, the min api level for android port is now 2.3
i've already "reimplemented" the sound plugin using OpenAL and the performances are much better.
I'm done with the android-native port, the code will stay in repositoy. maybe later, I'll clean the code and completly remove android-native stuff (if needed, I can still dig the repository history)
I've also updated the wiki pages.
If you are migrating from the native-android port, I suggest you start from scratch with demo/android as a template.
anyway if you have issues just ask here.
It's very rewarding to see your own efforts appear on a mobile device.
Now some extensive step-by-step documentation is needed to help those who just don't breathe this stuff everyday.
I will be needing to convert my project now (and get it under 1.4 too) and so a good docco will be handy.
I did make a start on a proper guide a few weeks ago, based on existing wiki material, so I'll revise that to suit the changes and see what you think.
go ahead with the wiki, it's not where I'm shining so any help is welcomed.
I'm planing for the mid-term to rewrite some internal part of glue code, hopefully it wont be to much intrusive for the user code (well... I'll do my best).
It's encouraging to see there is some love for this port, but what would be even more encouraging is to see releases using it :P