This page documents how 0 A.D. might be ported to the Android platform.

Plan

  1. Set up a generic Android NDK build environment.
  2. Find and adapt replacement libraries for every dependency in the PC edition.
  3. Port graphics and sound to OpenGL ES and OpenSL ES, respectively.
  4. Come up with a suitable UI for mobile devices.
  5. Implement the new UI on Android.
  6. Build the package with Android NDK and SDK.
  7. Publish the package on Android Market.
  8. Rock.

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.

Target devices

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

Design

User interface

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

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.

Entity selection

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.

Unit orders

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.

Input events

As far as I understand from the wiki, handlers for input events are specified in XML and JavaScript. So I am wondering if it would be a possibility to simply add a range of new events (e.g. TouchDown, TouchUp, etc.) for the engine to handle? Then the port could simply be supplied with a new set of XML and JavaScript files for the UI, but retain most everything else.

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.

Other dependencies

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 - This should be ported to OpenSL ES.
  • 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.

Optimizations

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.

Implementation

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

Next, install the Android SDK. Download the SDK package from this page to the working directory and then unpack it there, e.g.:

$ cd ~/android
$ tar -xvf android-sdk_r22.2.1-linux.tgz

Now complete the installation by running the android tool:

$ ~/android/android-sdk-linux/tools/android

A window with installable packages should open. In addition to any packages checked by default, make sure 'Android SDK Platform-tools' is checked and click 'Install packages'.

Google publishes a Native Development Kit (NDK), which is a set of tools for building native applications for the Android platform. Unfortunately, the official NDK does not and will not support the std::wstring (wide characters) datatype, which is required by the game, so we'll have to use the unofficial Crystax NDK. This is merely an extension of the official NDK, adding support for wide characters and other features maligned by Google.

Download the r8-crystax-1 NDK release from this page to the working directory and then unpack there, e.g.:

$ cd ~/android
$ tar -xvf android-ndk-r8-crystax-1-linux-x86_64.tar.bz2

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

Make sure Ant, Subversion and autoconf 2.13 is installed:

$ sudo apt-get install ant subversion autoconf2.13

On 64-bit Ubuntu you may need to install some 32-bit libraries:

$ sudo apt-get install ia32-libs

Finally, download the game sources from SVN to any location, e.g.:

$ svn co http://svn.wildfiregames.com/public/ps/trunk/ ~/android/0ad-game

Compiling dependencies and game

(These instructions are pretty imprecise, but in practice it's possible to get them to work with at least some versions of the game.)

First download SDL 2.0:

cd build/android/sdl-project/jni/
wget http://www.libsdl.org/release/SDL2-2.0.1.tar.gz
tar xvf SDL2-2.0.1.tar.gz
mv SDL2-2.0.1 SDL

Then build SDL and the .apk (the installable application that invokes the external game engine code):

cd build/android/sdl-project/
make

(Dependency checking is probably broken, so run "make clean" if you need to rebuild after changing stuff.)

Then install all the dependencies:

cd build/android/
./setup-libs.sh

The script hardcodes the expected locations of NDK and SDK, so put them there or adjust the script, and it will output to ~/android/toolchain-0ad. That should download and compile loads of stuff.

Build the game like:

cd build/workspaces/
./update-workspaces.sh --gles --android --without-audio --disable-atlas --with-system-mozjs185 --with-system-enet --with-system-nvtt --without-nvtt

cd gcc/
TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.6/arm-linux-androideabi/armv7-a/ -I../../android/sdl-project/jni/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug

Then attach a device, and in build/android/sdl-project/ run "make push-apk" and "make push-so". Run /sdcard/0ad.apk on the device to install.

The .apk is basically just the standard SDL android-project, and it loads /data/local/libpyrogenesis_dbg.so which contains all the engine code. That means you can recompile and then upload the engine code (via "make push-so") on the host PC, and don't have to manually reinstall the app after each change. If you want a non-debug build, remove the "config=debug" when building the game, then copy binaries/system/libpyrogenesis.so to libpyrogenesis_dbg.so before running "make push-so".

You need to use the game engine to create public.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

and it should print lots of output and will take a while (maybe ten minutes or more). Then copy to /sdcard/0ad/data/mods/public/public.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.)

Also, copy binaries/data/config/default.cfg into /sdcard/0ad/appdata/config/, and optionally set any local configuration values in /sdcard/0ad/appdata/config/local.cfg.

Then try running the game, and use "adb logcat" to see what fails, and fix it.

Last modified 9 months ago Last modified on Nov 12, 2013 6:24:04 PM