Setting up to compile for Android

[Baker]

Any thoughts, advice or tips for setting up to compile for Android using the NDK?

I intend to use the following as references:

1) https://developer.android.com/tools/sdk/ndk/index.html
2) http://code.tutsplus.com/tutorials/adva ... obile-2152

And I plan to poke around FTEQW's source code like usual.

I have a mapping project I want to finish by sometime around Christmas that *should* be very playable on mobile devices because I considered that by design, but I have some "different" ideas for mobile device controls and need to experiment.

[Spike]

here's the contents of my batch file to build debug builds:
make droid-dbg ANDROID_HOME=c:/Games/tools/android-sdk ANDROID_NDK_ROOT=c:/Games/tools/android-ndk-r8e ANT=c:/Games/tools/apache-ant-1.8.2/bin/ant JAVATOOL="/cygdrive/c/Program\ Files/Java/jdk1.7.0_02/bin/" -j8 DROID_ARCH="armeabi"

you'll need the right version of the sdk+ndk, as paths tend to get switched around a lot.
you can get an x86 build (arm+x86 in a single apk) with an alternative droid_arch term. this tends to run faster in an android-x86 virtual machine instead of emulating a different cpu.

fte's makefile just directly invokes the ndk's gcc to do the compile, system directories are fun. it then uses the android sdk to compile the java and package up the engine's .so file.
frankly, if you're going cross platform, the android build tools are a nightmare that are completely incompatible with makefiles, which is why FTE builds the .so file itself before doing the android-specific java+apk nonsense.
with later versions of the ndk, its possible to build java-less android programs (which use some system-provided thunks into native code or something).

for release builds, you'll be expected to use your own signing key (to prove that updates are released by the same person). The makefile will expect KEYTOOLARGS to exist in your environment settings (should be set to something like -keypass FOO). failure to do this will cause the makefile to prompt for one. You don't need to do this for debug builds.
You can set DROID_PACKSC=autoexec.cfg (for compressed data files) or DROID_PACKSU=foo.pk3 (for files that are already compressed) to add the named files to your apk file. FTE is able to use its apk file as a package, including recursively loading pk3/paks from it. You can include mod data this way.

[Baker]

As always, Spike thank you for your priceless advice.

And like always, it will be put to good use. Just watch. Yeah sure due to time constraints it may seem slow ... but Einstein always said time is relative .........

[Baker]

After a bit of a steep learning curve, I have to say this messing around with Android is relatively fun.

Android Studio is as awesome as Eclipse is terrible.

Not that I actually am using Android Studio, building via the command line is better but occasionally I want to open an IDE.

Now to see how truly friendly the Android NDK is with code that *should* be gcc friendly, since I always tried make CodeBlocks friendly compiles in the past.

[drm_wayne]

Does that mean we can expect a ProQuake or FitzQuake on Android?
Because FTE seems to crash often on bigger maps and Darkplaces doesnt show some things corretly.

[Baker]

[drm_wayne]

ftedroid has horrible controls, but darkpalces (Q4IA) has customizeable controls which is awesome.

[ceriux]

i was told on ftedroid the idea is to make your own controls via csqc.

[Spike]

with fte, you can add:
showpic forward.png fwd 64 64 0 64 64 "+forward"
showpic <imagename> <elementid> <x> <y> <origin> <width> <height> <command>
into your autoexec.cfg and this will add an on-screen button that you can touch to move forward.
I don't have a touchscreen on which to actually test fte myself, so yeah, the controls are likely not optimal.
and yes, you can write some csqc to snoop on the various inputs instead, which is probably a good idea if you're writing anything other than an fps anyway - csqc with a mouse cursor should be fine for various non-fps games. frankly, I'm quite paranoid about running an fps on a touchscreen, for view angles I can't really see it as working any better than a touchpad, and frankly those things are horrible. still, some people somehow manage to get efficient enough with them I suppose.

yes, ftedroid's controls do emulate a laptop touchpad, with two regions. onscreen buttons will certainly help supplement it, you'll just need to provide the artwork+autoexec.cfg commands yourself. :s

[drm_wayne]

But still it is crashing with no reason on some custom maps which are loadign fine in DP..

[Baker]

[drm_wayne]

[frag.machine]

[Baker]

Note: This Android NDK stuff is a bit sadist. And the Android stuff in general is over-engineered and not always in a good way (folderitis, hiding stuff in XML, hordes of generated files kludging up things, Eclipse is almost required with the NDK as Android Studio doesn't support it too much but I'm not disliking Eclipse as much as in the past).

But on the plus side, when the train runs off the tracks the answers are out there even if you have to expend some major effort to drill into it.

[Spike]

yeah, that's why I found it easier to just write out a .so with my own makefile, before invoking the sdk's build script for it (side note: msvc can invoke makefiles from the ide, if you want to go that route, just tell it to use gmake from msys/cygwin/etc instead of nmake).
yeah, you need some separate eclipse project in order to then debug it, but meh, printfs and logcat get the job done too. you can get stack traces from adb/logcat too.
if you can run the same code on windows/linux and get proper stack traces for crashes there instead, then its just much simpler that way instead of trying to get the user to figure out how to use a shell/adb/logcat stuff.
I guess its just personal preference: msvc > vim+make+stacktraces > everything else. saves having to deal with other UIs.

<offtopic>
incidentilly, if you're trying to crash FTE, please do it with this build - http://triptohell.info/moodles/win32/debug/fteglqw.exe - because it'll give you a stack trace that I can then try to use to find+fix the crash.

regarding HLBSP, the standard valve tools have usage restrictions upon them that limit their use in non-halflife engines - ie: they cannot be used. my memory is hazy, so be sure to read it properly.
</offtopic>