Any updates on things?
I haven't looked into the code as I wouldn't understand anything about it. Was just wondering if the effects and such are the problematic part I believe they could stripped off along with sounds if that's any help.
I doubt a lot of people will use game sounds on mobile games. I know I don't. Same goes for effects and stuff even in computer. I used to do highest details on ToME but on some levels (tempest peak 1) the slowdowns were horrible so the last few months I've been playing with minimal settings.
If those extra things could be easily stripped off the source one could imagine the source would be easily compileable on ARM processor architecture.
Just thought I'd give a quick update.
I've been half-on half-off over the past couple months, and finally reached the main part I've been dreading.
To give a brief intro, the main difficulties is that the source was written with desktops in mind. However, Android has a very... unique way of handling things. For starters, Android code is normally written in java, but can be written in C/C++ for advanced (read 'insane') programmers.
So, the process started like so:
1) Try building
2) See that it failed due to some missing requirement (such as OpenAL for music)
3) Find an android compatible source for that library
4) Add it to the build (symlink it in, and add an Android makefile)
5) Go back to step 1 and repeat
I managed to get it to the point where most
of the libraries compile no problem (openal, lua, luajit, physfs, etc.).
However, as I found out the hard way today, there's a huge hurdle with the graphics:
T-Engine was written using OpenGL
Android uses OpenGL ES
Of course, I had little to no knowledge in the differences between them, so I overlooked that little detail at the start.
Now, unfortunately, there's no easy button to go from one to the other. So, it basically boils down to 3 main choices for an android port:
1) Hack the source (partial rewrite), similar to what can be seen here: http://pandorawiki.org/Porting_to_GLES_from_GL
2) Rewrite the source entirely
3) Write a jumper library, similar to what's been done here: http://code.google.com/p/gl-wes-v2/
I'll probably take a look at the third option, and see how much can be ported/jumpered. Luckily, C++ is the perfect language thanks to the pre-processor directives.
Of course, there will be other difficulties (lack of keyboard, CPU/GPU limitations, etc) that will come up further along, but thought I'd give an update on the current one.
Should have more time these next couple months to work on it. Hopefully I'll be able to get through that so I can at least get something on screen.