I lucked out that my iPhone game was mostly in c with an objective c wrapper hosting the game. My Android port will nicely parallel. It will be an native c library compiled against the arm cross compiler. I will dynamically load the library into a Java shell app that will pump os level events to my app. Not sure yet how I will go the other direction.
Setting up my development environment was a breeze. Just check out the steps on http://developer.android.com/sdk/installing.html. I'm developing on a mac. Since I'm building the native - and by native that means NOT java - c library I needed the NDK as well as the SDK.
I followed a quick little tutorial on JNI. Just create a c file with a special name declaration that matches the stub in Java. Then call your java stub function after you load the c library and you are good.
I followed the recommended setup for putting all my c source under $(project)/jni. I created an simple Android.mk. I recommend reading all the docs in $(androidndk)/docs. There's a bunch of text files in there. They are not too verbose and get you the details you need to know.
All my source files were .mm instead of .cpp because they came from an iPhone project. I tried telling my makefile that .mm was the new .cpp, but it just complained that there was no objective c compiler and seemed to ignore my directive. So I changed all the file extensions to .cpp and the .h files were fine. Ok, now down to business.
I decided to keep the remnants of the iPhone code around and just create all my changes in an #ifdef ANDROID block. I started by adding one .cpp file at a time to the Andriod.mk file and then running $(androidndk)/ndk-build and #ifdefing out most of the things I couldn't fix and putting //TO DO's here and there. File IO was of course out. No bundle here. Typedefs were my friend for NSString and many other types. The entire OpenAl sound engine I stubbed out. Ahh, STL. I briefly read around and it appears that STLPort is the one most are using on the android NDK. Looking at my source, there wasn't too much use. So I took a templated vector class I had and adapted it to work for the usage. Quick fix for now, perhaps I will return to STLPort. There was a pathing source that had more use of STL. But it turned out that most of the #includes were not actually used (!) and just commenting them out and using my vector hack got me going. Thankfully all the OpenGL came over with little modification - for compiling anyway. And in just about 4 hours I had a brand shiny new libBattleShock.so - with large parts turned off :-) .
No comments:
Post a Comment