Setting up to compile for Android
Setting up to compile for Android
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
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.
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.
Re: Setting up to compile for Android
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 .........
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 .........
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
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.
Because FTE seems to crash often on bigger maps and Darkplaces doesnt show some things corretly.
Re: Setting up to compile for Android
I would be surprised if I don't have something done by the end of next week, but I don't know what form it will take yet.drm_wayne wrote:Does that mean we can expect a ProQuake or FitzQuake on Android?
Main thing will be to figure out a decent control scheme.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
ftedroid has horrible controls, but darkpalces (Q4IA) has customizeable controls which is awesome.
Re: Setting up to compile for Android
i was told on ftedroid the idea is to make your own controls via csqc.
Re: Setting up to compile for Android
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.
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.
Re: Setting up to compile for Android
But still it is crashing with no reason on some custom maps which are loadign fine in DP..
Re: Setting up to compile for Android
Could you name the maps because I'd like to know out of curiosity?drm_wayne wrote:But still it is crashing with no reason on some custom maps which are loadign fine in DP..
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
They are own HLBSP custom maps i made for my game, they run fine on PC (Darkplaces, Fitzquake), Android (Darkplaces) and PSP (DQuake Plus).Baker wrote:Could you name the maps because I'd like to know out of curiosity?
But FTE doesnt load them, you just get back to the Android mainscreen and FTE gets closed..
I dont think its a RAM issue since i can laod them on the PSP engine without problems.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Setting up to compile for Android
Have you tested the maps on FTE for PC ?drm_wayne wrote:They are own HLBSP custom maps i made for my game, they run fine on PC (Darkplaces, Fitzquake), Android (Darkplaces) and PSP (DQuake Plus).Baker wrote:Could you name the maps because I'd like to know out of curiosity?
But FTE doesnt load them, you just get back to the Android mainscreen and FTE gets closed..
I dont think its a RAM issue since i can laod them on the PSP engine without problems.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Setting up to compile for Android
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Setting up to compile for Android
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>
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>