Add support for Android tablet devices

[omcfadde]

90% complete, 90% remaining...

[kkszysiu]

Damn I just started to make the same thing! :D

[omcfadde]

You're welcome to go ahead. I'm running into some weird problems with thread synchronization and memcpy() bugs that shouldn't be possible... you might very well complete the work before me.

[kkszysiu]

I don't know yet what I'm heading atm... I prepared scripts to compile everything and for now I'm stuck there. I will work on NativeActivity wrapper now :)

[kkszysiu]

Some works done. Far from perfect but...

https://plus.google.com/u/0/108396638562408971291/posts/MyFmnGBPPec :)

[omcfadde]

Nice work! :-) Please push the code onto Github so that I can take a look at improving it and merging into Dante.

[kkszysiu]

I will try to clean up those mess soon and upload it on different branch for now.

BTW. I have more than 30 fps on my DHD on test_box map but it took almost 3 minutes or more to load it :D

[omcfadde]

Great, thanks. It's okay if the code isn't perfectly tidy. 30 fps is very respectable, but I believe this can be improved upon. I have a few ideas.

[kkszysiu]

Yeah, I know... youre GLES 2.0 master here :D There's still a lot to do but it is at least something... code cleaning is required mostly because hardcoded paths etc... but I will try to fix it soon and I will prepare readme for all those who want to compile it :)

https://plus.google.com/u/0/108396638562408971291/posts/6dJwiANyC66

[havlenapetr]

I wrote native android makefiles into your project: https://github.com/havlenapetr/idtech4 for ndk build

[kkszysiu]

Is it working? I didnt check your code yet... I'm still using scons to build everything. Do you have working sound?

[kkszysiu]

I need to work on sound soon... we should use native OpenSL support on Android instead of OpenAL if it will be possible but for now we could use OpenAL if we don't have anything else. For now Im using null sound because I don't wanted to load huge sound sample files just yet.

[kkszysiu]

https://github.com/kkszysiu/dante/tree/android/android here you go :)

[omcfadde]

Very nice, thanks. :-) There are of course a couple of minor clean up issues (white space and line endings etc) but that's nothing I can't take care of while merging.

You've definitely secured yourself a place on the Dante credits GUI screen (once that's implemented!) Until then, I'm thinking of adding an `AUTHORS' file like most of the GNU projects.

[kkszysiu]

Did you compiled it successfuly?

[havlenapetr]

I have working openal impl for android: https://github.com/havlenapetr/openal but you must compile it against android full source code and than use it like prebuilt with ndk.

[havlenapetr]

and yes compilation works, I am debugging app right now

[kkszysiu]

Yes, OpenAL works but it doesn't have support for fixed-point decoding. The same as vorbis so you will have propably huge decrease in performance on sound... so best choice is to reimplement whole sound soundsystem using libtremor (fixed-point libvorbis equvalent) and OpenSL (native Android sound implementation, prepared for low-latency, embedded purposes).

[havlenapetr]

I know, but OpenSL is implemented only on newer devices. BTW doom code is pretty hungry in performance too

[kkszysiu]

Yeah so we don't need support for older devices. Doom 3 won't work on them anyway... OpenSL is introduced in Android 2.3, the same as NativeActivity so Android 2.3 should be minimal requirement (We will still need ARMv7 CPU and NEON set on device anyway (and most of Android 2.3 powered devices has them, excluding chinese tablets for 20$), without it there's no even chances that Doom 3 will work smoothly :))

[havlenapetr]

right, my port works on native activity too, I will push it and start working on OpenSL backend

[kkszysiu]

BTW did you tried to build Doom 3 using my code? I want to be sure my how-to in README is easy to understand...

[havlenapetr]

nop, i will try, I am at work right now :-)

[omcfadde]

kkszysiu, it's a good idea to use `set -e' in your Bash script, e.g.

#!/bin/bash
set -e

This means that your script will not continue if a command fails; it has some exceptions, but they are there for good reason. See `man bash'

-e      Exit immediately if a pipeline (which may consist of a single simple
        command), a subshell command enclosed in parentheses, or one of the
        commands executed as part of a command list enclosed by braces (see
        SHELL GRAMMAR above) exits with a non-zero status.

Yes, I have been able to compile your sources, with some modifications for trivial things like a couple of hard-coded paths, etc. Nothing major. I'm currently in the process of updating of my Android SDK and NDK, then I'll do a rebuild and look at merging this into Dante (possibly with GNU Autoconf/Automake, depending on how much time and effort I'm able to put into this in the immediate future.)

I absolutely want to get rid of SCons; it's a terrible build system.

[kkszysiu]

Do you think that Autoconf/Automake is better solution?

[omcfadde]

Yes, I do, and this may just be because I'm more familiar with GNU tools and find them easier to use.

It's not my intention to start a build system argument, but if I can do something easier with GNU Autoconf/Automake than with SCons, I'm going to use the GNU tools.

[havlenapetr]

Hi, do you know what this error means, please:

---------- R_GLSL_Init ---------- I/Doom (22202): Not available. I/Doom (22202): ----- R_ReloadGLSLPrograms ----- I/Doom (22202): gl2progs/interaction.vert I/Doom (22202): I/Doom (22202): gl2progs/interaction.frag I/Doom (22202): I/Doom (22202): TODO: Sys_SetClipboardData I/Doom (22202): **** I/Doom (22202): ERROR: R_LinkGLSLShader: program failed to link I/Doom (22202): I/Doom (22202): **** E/Doom (22202): Error during initialization

i have yours gl2progs/ in base dir and it looks like everything works, except: glGetProgramiv(shaderProgram->program, GL_LINK_STATUS, &linked); because linked is 0

[omcfadde]

Please run again with `+set developer 1' so that I may see the shader compiler messages.

Please also open your own bug here on the issue tracker. You are using the Android version, but this is a separate issue.

[kkszysiu]

Ok guys, no hardcoded paths anymore :) I fixed it in my latest commit.

[havlenapetr]

sorry, issue #17

[kkszysiu]

omcfadde, do you have any idea how to make virtual joystick in idTech4/OpenGL ES 2.0? Do I need to write own shader to archieve it?

To be honest I'm not so much experienced with OpenGL ES 2.0. I was working with OpenGL ES 1.0 but 2.0 and whole shaders is a new thing for me...

[omcfadde]

Well, no, a GLSL shader is not needed. I had some idea to have a circular area on the left and right bottom corners of the screen which would basically function like the analog sticks on game console controllers. Add some buttons along the top or bottom of the screen for weapon selection. This is stuff that would be done in game code and/or by editing the *.gui files. You might also need a material shader (Doom 3 material shader, not GLSL) and a texture for your virtual analog sticks.

If you want something quick and easy, you could use the accelerometer (tilt forward to move forward, back to move back, angle left/right to strafe left/right) aiming/shooting could be done on the touchscreen. I don't think this is a really good solution, because I did something similar for Maemo Quake 3. It worked, but it's not a great experience.

Third option is a tablet stand and Bluetooth controller (PS3 DualShock works nicely with Linux, shouldn't be too much trouble with Android.)

Really input on mobile devices is not a solved problem. It's a difficult problem...

[omcfadde]

Oh, and I promise to try to get the Android work from kkszysiu merged into Dante during the weekend. Hopefully. Real life often makes other plans...

[kkszysiu]

I already implemented accelerometr solution. Will commit it soon but as you said it's not the best idea to control movements using accelerometer.

The best solution will be on OVUA console propably (if performace will be good enough) :D Bluetooth joystick or keyboard/mouse will be good suited here too I think. Sadly I don't any of those things yet :)

[havlenapetr]

you can use keyboard and mouse via usb host feature. I've tested my build on i9000(1GHz CPU, PowerVR GPU, 512MB RAM shared with GPU) and fps is about 10-15frames per second, which is pretty low:-) maybe we should start working on optimalizations(SIMD ...), I know that on tablets and highend phones fps will be better, but I don't know how much better. And I don't understand why is this engine so slow against quake 3 arena engine, which is pretty fast. What is causing this low fps (bigger assets?), because source code is very similar to quake 3 arena. I will upload demo video tomorow. BTW I've started working on OpenSL audio driver, maybe tomorow I will be able to publish it

[kkszysiu]

Which level youre loading? test_box one?

[kkszysiu]

Well Quake 3 engine is faster because it doesnt used shaders, lights etc, that's why it's faster. Models have higher quality in Doom 3 too, engine is simillar from common side but whole graphics stuff is rewritten to meet 2004 year requirements.

[kkszysiu]

Maybe try our build, you should get better performance I think :) I have simillar hardware (My GPU is Adreno 205) and I have around 30 fps on test_box map.

[omcfadde]

Quake 3 is doing almost nothing in the vertex and fragment shaders; it doesn't use the programmable pipeline. Doom 3 makes extensive use of the GPU, in fact off-loading as much work as possible to the GPU. This is the primary reason for the performance difference, not the assets. Simply put, Doom 3 is performing more calculations per vertex and fragment.

You may gain some more performance by reducing the precision statements, but be very careful with the matrices. I would keep the MVP at highp and default everything to mediump. Vertex color attributes could possibly be reduced to lowp.

Of course this depends on the hardware. Imagination SGX may give totally different results than Nvidia Tegra when reducing the precision. There is also a divide in the vertex shader to convert the vertex color from 0-255 range into 0-1 range. This could be done on the CPU.

[havlenapetr]

ok, thanks for info (I am not very familiar with GL stuff), I've found this: http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/BestPracticesforShaders/BestPracticesforShaders.html#//apple_ref/doc/uid/TP40008793-CH7-SW3, there is some info about colors and lowp (how you wrote) in shaders. 10-15fps I am getting in menu, I don't know if your GNU build could be faster, I think that we should have same fps, because we are both building same source code with probably same optimizations. Are you building armv-7-neon build or just armv6 version? Where I can get test_box map, please?

[kkszysiu]

My build have hardcoded setting to always load test_box map, I changed common->Init method to this one:

common->Init(0, NULL, "+devmap testmaps/test_box");

[havlenapetr]

I am using standart common->Init(0, NULL, NULL) calling, but where I can get test_box file? I don't have it in my datas

[kkszysiu]

Are you using original Doom 3 paks? If yes, then you should have it.

[kkszysiu]

BTW on test_box map I have 26-30 fps without much FPS drops.

[kkszysiu]

Ok, really simple movement system using accelerometer implemented - forward and backward for now...

[havlenapetr]

I don't have test_box map in my assets, so I can't test test_box map right now, here is demo video: https://plus.google.com/photos/101582304371073858214/albums/5774194308102696945 (sometimes I have problem with colors and alpha like on video, but in most startups everything is correct, i don't know why this is happening sometimes)

[omcfadde]

havlenapetr, it's possible, though unlikely, that your *.pk4 files were corrupted during transfer. The only reason I suggest this is because it actually happened to me on my Galaxy Tab. I couldn't figure out why I would receive an error regarding "Couldn't load ... for player_model" (quoting from memory.)

It turned out, that for whatever reason, adb push-ing each of the *.pk4 files to the SD card again resolved the problem. It's a bit of a wild guess, but maybe you can try it.

Make sure you're executing the command +devmap testmaps/test_box because using +devmap test_box won't work.

[havlenapetr]

Can I ls installed maps somehow?

[kkszysiu]

I don't know it is possible from game but you can open your pak000.pk4 in winrar or different archiver then look at /maps/testmaps.

[havlenapetr]

I've commited my doom3 port: https://github.com/havlenapetr/adoom3 and here is audio driver: https://github.com/havlenapetr/adoom3/blob/master/jni/audio.cpp it needs some rework, now plays ugly sounds :-) probably it should be rewritten into async callback OpenSL style