..Any suggestions for a Android Quake engine?

[mankrip]

The sound lag almost disappeared now, good job.

I'm installing the Android SDK right now. Is there anything specific I need to configure or install to get FTEDroid compiling properly?

[Spike]

you need these: android sdk. android ndk. ant. java jdk. cygwin (or mingw's gmake instead I guess)
note that I also have cygwin installed, and use it for gmake

excerpt from my batch file:
cd engine && make droid-rel DROID_ARCH="x86 armeabi" DROID_SDK_PATH=/cygdrive/c/Games/tools/android-sdk DROID_NDK_PATH=/cygdrive/c/Games/tools/android-ndk-r7 ANT="c:/Games/tools/apache-ant-1.8.2/bin/ant" JAVA_HOME="c:\Program Files\Java\jdk1.7.0_02" JAVATOOL="/cygdrive/c/Program\ Files/Java/jdk1.7.0_02/bin/"

will compile ftedroid for arm devices as well as android-x86
cygwin must be in your path. the other paths can be tweeked via the commandline as above.
if you're compiling on linux, you can drop the ant/java paths entirely, but you'll still need to specify the droid paths.

to install it on your device:
c:\Games\tools\android-sdk\platform-tools\adb.exe install -r release/FTEDroid.apk
(or you can set up an http server and install it over wifi or whatever, assuming you device is set to allow installs from 3rd party locations).

[mankrip]

Is there a way to make the engine use a network folder instead of ID1? This would make testing a lot quicker and simpler. I'm getting some crashes here, and it takes quite a while to plug, copy files and unplug the device every time I test a different file.

By the way, savegames seems to be almost working now. They can be loaded, the weapon slots are set correctly, but all the ammo is depleted and the player's self.origin seems to be set to '0 0 0'.

Also, I just checked, and replacement textures aren't being loaded. They do work fine in the Windows version of FTEQW, though.

[Spike]

fte has a cl_pure cvar which causes the client to use only the pak files the server says to use.

fte can download files as it needs from the server (though md3s or other similar model formats can have such awkward dependancy chains that it doesn't try to download them all, or even know that it should). So you could just add each mdl to the server and let the client download until you find the problematic one.

but no, there's no way to get fte to use a network location for all its data without directly mounting it on your android device's filesystem (eg: nfs).

[mankrip]

I've just installed , which will surely help a lot.

I hadn't thought of mounting a network folder directly into the filesystem, but I'll certainly do this too.

[xaGe]

..It kind of sucks after 3 months my battery in the YDPG18 has appeared to have died! Doesn't seem to want to hold a charge. It will run off of the charger when plugged in at least, but defeats the purpose of a "hand held" device. If its just the battery guess I could try to crack it open and do some sort of replacement or battery mod when I find time.

[mankrip]

I've finally got around to installing everything and compiling it.

The compiling time was so long (despite the fact that it gets compiled twice, one for x86 and another for ARM) that I got afraid to think about how big its source code must be. I usually do a clean compiling of Makaqu every time I change something in the headers, but this would be certainly unpractical with FTEDroid. Anyway, what matters is that it's a really powerful engine.

After installing it, I noticed the latest source release (I've got the SVN tarball less than 24 hours ago) uses the external SD card for the data, but it uses the root dir instead of the FTE dir, so I had to put my ID1 directory directly into the root dir.

I've also noticed that now a graphical presets menu shows up when starting the game.

And when trying to play a demo or start a new game, be it either single player or multiplayer, the engine closes. I've tried changing the presets, but got the same result for each of them. The menus and console displays properly though.

There are too many warnings when compiling this engine, so I have no idea where to start looking in to try to fix it.

[Spike]

make droid-dbg DROID_ARCH=armeabi -j8
is the line I'd use to compile a 'debug' version.
note that fte's makefile should have proper dependancies, so you'll only need to make clean if you change the makefile/CFLAGS.

There are a lot of warnings, yes. Generally I do all my development/testing with msvc, which simply doesn't generate those same warnings. that's my excuse and I'm sticking to it.
If you're paranoid, try adding this to the make line: CFLAGS=-fno-strict-aliasing
That should remove the bulk of the warnings by removing the point of warning about them in the first place, but it might run a little slower.

The graphical presets menu is a little pointless on android, you probably want the second or third option. the first is a little too extreme really, and is present more for the visibility than for screenshots. The last two will eat too much performance on embedded devices. Pick the third if you want it to default to vanilla-like settings.

The engine 'closing' is it crashing. Either a segfault or a sys_error. If you run logcat (from adb or a shell on the phone itself, even after it crashed) then it should show various stuff including all Sys_Print calls (including console prints and any sys_error messages).
Any segfaults should be accompanied by a register dump and a stack trace, although I've generally not found the stack trace useful for crashes in native code.

A quick overview of interesting rendering function calls:
R_RenderScene (gl_rmain.c) - sets up the projection+world matricies, frustum
Surf_DrawWorld (r_surf.c) - figures out which world surfaces/batches are visible
GLBE_DrawWorld (gl_backend.c) - does the actual rendering work.
BE_GenModelBatches (gl_alias.c) - generates batch lists from entities (non-world bsp+mdl+spr+etc) for the backend to render.

if you're getting a crash on starting a new map, then chances are its either low memory (check for Sys_Errors) or a gl/backend crash (GLBE_DrawWorld + gl_backend.c)
It could also be part of model loading, gl_rsurf.c has a function 'GLBE_GenBrushModelVBO' which is called to prepare some vbos.

[mankrip]

I can't copy or even look at the log from logcat, because the thing won't stop flooding itself with useless messages, and it gets even worse when I long-click to open the context menu.

However, I can confirm that your current build is also crashing when trying to load any map.

[Spirit]

You can set logcat to a less verbose level. You can also make it log to disk.

[mankrip]

[Spike]

adb logcat ActivityManager:I FTEDroid:I DEBUG:I *:S
supposedly should filter log output to just fte's Sys_Printf calls and system crash dumps/errors.

Before I continue, I should mention that I *think* its already fixed.

Your crash log basically says its a null pointer dereference in my code. Sadly the program counter address is almost useless, as its specific to that build, and is not corrected for randomized module load addresses.
This basically means addr2line isn't usable. Which is why any android-related crashes I've had have been fixed using Sys_Printfs. :s

Side note: the android emulator has (fixed) gpu acceleration in it now. Its also possible to use an x86-targetted version, which allows you to use accelerated cpu virtualization stuff too.
This has allowed me to get a gles2 context up and running in the emulator (natively, this needs android 2.2).
I added some const that you can change to 2 if you want to try gles2 instead, but the version on the svn is set to use gles1. It'll still fall back on gles1 if gles2 doesn't work (like in non-gpu-accelerated emulators), so should be safe if set by default, but I'm paranoid.
You can get a gles2 context up and running in windows by setting vid_gl_context_es2 1, assuming your gl drivers support the extension. This allows debugging with a real debugger instead of the awkward android-targetted gdb.
That doesn't really help with gles1-only crashes though.

[mankrip]

I just reinstalled the precompiled APK from your link in the first page of this thread, and it still crashes, same as before.

Could the stated resolution have any impact? On the console it says to be using a 640x480 video mode, but my device actually runs it at 800x480.

[Spike]

the 640*480 thing is irrelevent.
I don't think the nightlies have been recompiled yet.
poke me on irc (quakenet, #fte) and I'll put up an http server with a build on it that you can try and install directly to your device (or PM me an email address and I'll email the apk to you).

[mankrip]

No need, thanks. I've finally got around to learning how to download the source using TortoiseSVN, and the current version does load properly.

of it in action. The lightmaps gets animated like crazy when loading a game, and the lighting becomes blocky when the screen orientation changes.

After that I looked at its java code to find a way to make the engine ignore the device's orientation, but then I remembered that games that have an option to force an specific orientation also affects Android's notification bar, so it must be a matter or instructing the OS itself to force that.

I've also tried reducing the audio buffer to 256 bytes to see if the audio lag would practically disappear, but setting it to any value lower than 2048 made the sound stop working, so I reverted it back to 2048.
I've also tested some other games, and even Android games like Sonic CD have some audio lag. However, games from doesn't seem to have any audio lag, but they're most likely fully coded in Java, as they're also a JME developer and several (maybe all) of their games in Google Play are ports of their JME games for older cell phones. Maybe the audio lag is due to something with the NDK?

The last time I've tried, FTEDroid didn't use any of the external textures I've tried. Is there any external texture format that should work in the current version?

And the MDL skin mapping seems to be slightly off, as the end of the super shotgun model included in Makaqu displays parts of its muzzleflash skin. This isn't a problem for me, but may be a problem for others using custom content.

By the way, regular skies works great now.