Table of Contents
This page documents how 0 A.D. might be ported to the Android platform.
- Set up a generic Android NDK build environment.
- Find and adapt replacement libraries for every dependency in the PC edition.
- Port graphics and sound to OpenGL ES and OpenSL ES, respectively.
- Come up with a suitable UI for mobile devices.
- Implement the new UI on Android.
- Build the package with Android NDK and SDK.
- Publish the package on Android Market.
The port is very much a work-in-progress. If you are technically inclined and want to help out, follow the steps under the Implementation section below, read the error output generated by the compiler, and suggest solutions here or on the forum.
Nexus 7 (2013)
- 1920x1200 px at 323 ppi
- 16:10 aspect-ratio
- Multi-touch, capacitive touchscreen
- 1.51 GHz quad-core Krait 300 ARM CPU
- 400 MHz quad-core Adreno 320 GPU (OpenGL ES 3.0)
- 2 GB DDR3L RAM
Due to the vastly different controls and form factor, the whole user interface of the game needs to be rethought.
In the following, each control primitive is summarized as a bullet point.
We will use the following terminology for basic gestures:
A swipe is a single-point touch motion.
A pinch is a two-point touch motion.
Camera panning is performed by applying inverse swipe gestures on the screen:
- Swipe down - pan camera forward.
- Swipe up - pan camera backwards.
- Swipe left - pan camera right.
- Swipe right - pan camera left.
The further from the center of the screen the swiping motion begins, the faster the panning will be.
Camera rotation is performed by applying a circular pinch gesture on the screen:
- Pinch clockwise - rotate camera counter-clockwise.
- Pinch counter-clockwise - rotate camera clockwise.
When the circular gesture is complete, the camera shall have completed a full rotation.
Camera zoom is performed by applying a pinching gesture on the screen:
- Pinch in - zoom out.
- Pinch out - zoom in.
The camera may also be panned by touching near the edge of the screen:
- Touch near edge of screen - pan camera in the direction of the given edge.
The camera may also be panned by touching a position on the minimap:
- Touch position on minimap - pan camera to the corresponding position on the map.
If an entity is tapped once, the entity is immediately selected.
- Single-tap entity - immediately select entity.
If touch is applied to the game world for more than ~0,25s, a brief tactile feedback vibration is played, and the interface enters 'selective mode.'
- Touch game world for more than ~0,25s - enter 'selective mode' and play brief tactile feedback vibration.
While in selective mode, a bounding box is drawn with one corner where the touch point was when the mode began ('start position') and the opposite corner where the touch point currently is ('end position'').
While in selective mode, the camera pans slowly in the direction from the start position to the end position. The further the touch point currently is from the point on the screen where it was when the mode began, the faster the camera pans.
When touch is released in selective mode, all units within the drawn bounding box are selected.
If a position in the game world is double tapped, the selected unit is ordered to apply its context-dependent primary action to the position.
- Double-tap position in game world - apply selected unit's primary action to the position.
The game's input events originate from SDL, so the real question is does SDL support these Android-specific events? At least in the development branch there is an SDL_TouchFingerEvent that should work for this. You only need to add new events to the GUI XML schema if you're going to add new GUI object types, which might be reasonable on an Android port. I'm thinking it would be easiest to avoid that until absolutely necessary. Either way the GUI manager will need to be extended to capture these events and pass them onto scripts like the session input.js, which is where the most interesting event handling occurs (unit selection, building placement, etc.) Unfortunately the GUI engine code is a mess.
Check out HandleEvent in source\gui\CGUI.cpp. See also EGUIMessageType in GUIbase.h. In fact you should be familiar with most of source\gui. For the XML parsing you'd want the CGUI::Xeromyces_* methods at the bottom of CGUI.cpp. For camera movement, see the CGameView class in source\graphics\GameView.cpp.
Graphics (mostly outdated)
Android includes support for high performance 2D and 3D graphics with the Open Graphics Library (OpenGL), specifically, the OpenGL ES API. Since the game utilizes features of the full, standard OpenGL API, these portions of the code will have to be migrated to OpenGL ES.
I think the best approach is to extend graphics/ShaderProgram.cpp to support GLSL shaders (it was designed with that in mind, but I don't know if it'll actually work without some interface changes); then move all the renderer's existing fixed-function texture-environment setup code into ShaderProgramFFP.cpp and implement GLSL-based equivalents, so that most of the rest of the renderer code doesn't have to care whether it's using FFP or GLSL (it just uses the CShaderProgram interface). Also, change all immediate-mode drawing (glVertex3f etc) to vertex arrays. I think that should deal with the most serious problems, and the code would all be shared between GLES and desktop GL modes (no need for forking or #ifdefs etc) and can be tested with desktop GL. Then there's probably just lots of little issues remaining, which can be addressed as they occur.
The basic strategy is that any fixed-function multitexture setup code (glTexEnvi etc) should be moved to ShaderProgramFFP.cpp, and the rendering code should load it via g_Renderer.GetShaderManager().LoadEffect(...), so that we can easily add a GLSL-based implementation of the shader later. Then the rendering code should replace calls to glVertexPointer(...) etc with shader->VertexPointer(...) (which translates the fixed-function arrays into generic vertex attributes for GLES-compatible GLSL). Then replace all glBegin/glVertex3f/etc drawing with vertex arrays and glDrawArrays. Then replace the GL global matrix stuff with client-side computation of the model-view-projection matrix, and pass it to the shader with shader->Uniform("transform", m). I think the shader API provides everything that's needed for this now, so the remaining work is mostly just mechanical translation.
Android-compatible replacements must be found for all the dependencies of the PC edition. This is what we have so far:
- GCC - The Android NDK provides its own toolchain for compiling.
- Subversion - Assuming this is just for obtaining the source, this can be done on a PC workstation.
- SDL - This is already in SDL2.
- Boost - There is an unofficial port.
- zlib - libz is part of the native NDK.
- libpng - Compiles natively against the NDK.
- libxml2 - Compiles natively against the NDK if iconv bindings are disabled.
- OpenGL - This must be ported to OpenGL ES.
- OpenAL - Compiles natively against the NDK.
- zip - Not sure which exact library this refers to?
- libogg - May be covered by Tremor (below).
- libvorbis - This can be done with Tremor.
- libcurl - Compiles natively against the NDK.
- Gamin - This can be disabled at build time. The game will run fine without it.
- CMake - The port can be integrated with the standard build system using the standalone NDK toolchain.
In addition to the external dependencies above, the following are bundled with the game:
- NVTT - We don't need any of its fancy features like CUDA support or image-loading tools, just the basic CPU-only compression library, so it should be buildable with no significant external dependencies (though its build system might need fixing).
- Spidermonkey - Spidermonkey has been ported as part of Fennec. We can't use Android's native V8 engine since we rely on some complex API features, so porting would be a huge amount of work. SpiderMonkey isn't API-compatible or behaviour-compatible across versions, so it'd be best to use the same 1.8.5 release as we use on PCs if possible.
- Enet - Compiles natively against the NDK.
- FCollada - We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work. Our own version has no significant dependencies other than libxml2.
The target device supports the ARM NEON SIMD instruction set. In turn, it does not support the x86 SSE SIMD instruction set. Hence, it would be relevant to 1) identify portions of the code that use x86 SSE and port them to ARM NEON, and 2) identify portions of the code that lends itself well to SIMD processing, but doesn't currently target either instruction set, and port them to both, and thereby achieve a speedup on both ARM and x86 architectures.
The target device features a dual-core processor. Unfortunately, the game doesn't really take advantage of multicore systems yet. This could be improved with multithreaded AIs and pathfinding.
The Android VM allows applications to call methods implemented in native code through JNI. This means we have to produce a native shared library which implements the core game functions as a set of methods (functions) which can be called from a shim running in the standard Android VM. The native library and the shim can then be packaged and distributed together as a standard Android application.
Setting up your workstation
For everything short of actually running the application, we will use a PC workstation. This section will assume your workstation runs Ubuntu Linux, but the steps should be relatively easy to adapt to other platforms. Begin by setting up a working directory for the project:
$ mkdir ~/android
$ cd ~/android $ tar -xvf android-sdk_r24.0.2-linux.tgz
Now complete the installation by running the
A window with installable packages should open. In addition to any packages checked by default, make sure Android SDK Platform-tools, and Android 4.4.2 (API 19) -> SDK Platform are checked and click 'Install packages'. Android 4.4.2 (API 19) -> SDK Platform is needed only to build the APK, the game will still run on lower API (it needs API-12 or higher).
Download the official NDK.
$ cd ~/android $ chmod +x android-ndk-r10d-linux-x86_64.bin $ ./android-ndk-r10d-linux-x86_64.bin
By default the script that will download & build all Pyrogenesis' dependencies will search for Android SDK & Android NDK in the following locations:
If you don't want to pass their location manually, then you have to rename them.
You also must install a Java Development Kit (JDK) if you haven't already, e.g. the standard JDK from Ubuntu Software Center:
$ sudo apt-get install default-jdk
$ sudo apt-get install ant subversion autoconf2.13 wget git
On 64-bit Ubuntu you may need to install some 32-bit libraries:
$ sudo apt-get install ia32-libs
Download and install Qt SDK for Android. Pyrogenesis doesn't depend on Qt, it needs it just to build the engine and create APK. You'll use QtCreator to manage, build, run & debug on Android Pyrogenesis. If you are not used with QtCreator, here you can find its reference card.
Finally, download the game sources from Git to any location, e.g.:
$ git clone https://github.com/bog-dan-ro/0ad.git
Compiling dependencies and game
Build & install all the dependencies:
cd build/android/ ./setup-libs.sh
The script searches for NDK in ~/android/android-ndk if you have it in another location then use -n parameter to pass its location. The script should run without problems. If fails and you can't fix it, please contact us, otherwise you'll not be able to compile Pyrogenesis.
Next step is to setup QtCreator for Android. This article explains you how to do it.
After you've finished to setup QtCreator for Android, then you can open the project from
0ad/build/android/qtcreator/qtceator.pro. After you open the project, make sure you choose an Android KIT, check first part of this article for more information.
Do not try to start the game if you didn't push the game data (check the next step).
You need to use the game engine to create
mod.zip for data files, since it has to convert all the textures/models/animations/etc into a different format before zipping them up. Build a standard non-Android copy of the game, then run it like
$ mkdir temp $ ./binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip -archivebuild-compress $ ./binaries/system/pyrogenesis -archivebuild=binaries/data/mods/mod -archivebuild-output=temp/mod.zip -archivebuild-compress
and it should print lots of output and will take a while (maybe ten minutes or more).
Then copy them to your device:
$ adb push -p temp/public.zip /sdcard/0ad/data/mods/public/public.zip $ adb push -p temp/mod.zip /sdcard/0ad/data/mods/mod/mod.zip
and the game should see it. (If you want to change a few data files after that, you don't need to regenerate
public.zip - just copy the individual files straight into
mods/public/ and they'll override the zipped version.)
/sdcard/0ad/appdata/config/default.cfg, and optionally set any local configuration values in
$ adb push binaries/data/config/default.cfg /sdcard/0ad/appdata/config/default.cfg
Then finally, try running/debugging the game using QtCreator (press Ctrl+R run, F5 debug).