[[TOC]] This page documents how 0 A.D. might be ported to the [http://www.android.com/ Android] platform. == Plan == 1. Set up a generic Android NDK build environment. 1. Find and adapt replacement libraries for every dependency in the PC edition. 1. Port graphics and sound to OpenGL ES and OpenSL ES, respectively. 1. Come up with a suitable UI for mobile devices. 1. Implement the new UI on Android. 1. Build the package with Android NDK and SDK. 1. Publish the package on Android Market. 1. 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 [http://trac.wildfiregames.com/wiki/AndroidPort#Implementation Implementation] section below, read the error output generated by `ndk-build`, and suggest solutions here or [http://www.wildfiregames.com/forum/index.php?showtopic=15436&view=getnewpost&hl=&fromsearch=1 on the forum]. == Target devices == === Samsung Galaxy Nexus === * 720×1280 px at 316 ppi * !16:9 aspect-ratio * 16M colors * Multi-touch, capacitive touchscreen * 1.2 GHz TI OMAP 4460 ARM Cortex-A9 dual-core CPU * 307 MHz PowerVR SGX540 GPU * 1 GB RAM == Design == === 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 [http://wiki.libsdl.org/moin.cgi/SDL_TouchFingerEvent 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''. === 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 up. * Swipe up - pan camera down. * 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. The closer to the center of the screen the pinching motion begins, the faster the rotation will be, such that when the circular gesture is complete, the camera has 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 end position is from the start position, 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. === Graphics === 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. === Other dependencies === Android-compatible replacements must be found for all [http://trac.wildfiregames.com/wiki/BuildInstructions#Linux the dependencies of the PC edition]. This is what we have so far: * ''GCC'' - The Android NDK provides its own `ndk-build` tool for compiling. * ''Subversion'' - Assuming this is just for obtaining the source, this can be done on a PC workstation. * ''SDL'' - Is already [http://www.libsdl.org/tmp/SDL/README.android ported to Android]. * ''Boost'' - There is [https://github.com/MysticTreeGames/Boost-for-Android an unofficial port]. * ''zlib'' - libz is part of the native NDK. * ''libpng'' - There's unofficial ports like [https://github.com/julienr/libpng-android this one]. * ''libxml2'' - Google publishes [https://github.com/android/platform_external_libxml2 a tree] that is tuned to compile on Android. * ''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 [http://www.badlogicgames.com/wordpress/?p=451 done with Tremor]. * ''libcurl'' - May be ported [http://thesoftwarerogue.blogspot.com/2010/05/porting-of-libcurl-to-android-os-using.html like this]. * ''Gamin'' - Don't know about this one. It's used for monitoring file hotloading which doesn't seem as useful on an Android device. * ''CMake'' - All build tools are provided by the NDK. In addition to the external dependencies above, the following are bundled with the game: * ''[http://code.google.com/p/nvidia-texture-tools/ 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'' - Presumably, Spidermonkey has been ported as part of [https://wiki.mozilla.org/Mobile/Fennec/Android 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 [https://developer.mozilla.org/en/SpiderMonkey/1.8.5 1.8.5] release as we use on PCs if possible; I think the standard releases are meant to work on ARM, so that should be okay. * ''Enet'' - From a quick check, I see no dependencies outside of libc, so this should compile natively. * ''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. == Implementation == The [http://en.wikipedia.org/wiki/Dalvik_(software) Android VM] allows applications to call methods implemented in native code through [http://docs.oracle.com/javase/7/docs/technotes/guides/jni/index.html 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 [http://en.wikipedia.org/wiki/Shim_(computing) 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 }}} 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, which is merely an extension of the official NDK adding support for wide characters and other features maligned by Google. Next, [http://developer.android.com/sdk/installing.html install the Android SDK]. Download the SDK package from [http://developer.android.com/sdk/index.html this page] to the working directory and then unpack it there, e.g.: {{{ $ cd ~/android $ tar -xvf android-sdk_r16-linux.tgz }}} Now complete the installation by running the `android` tool: {{{ $ ~/android/android-sdk-linux/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'. You also need to install the Android NDK (!r4 or later). Download the NDK package from [http://developer.android.com/sdk/ndk/index.html this page] to the working directory and then unpack there, e.g.: {{{ $ cd ~/android $ tar -xvf android-ndk-r7-linux-x86.tar.bz2 }}} You also must install a Java Development Kit (JDK) if you haven't already, e.g. [https://apps.ubuntu.com/cat/applications/oneiric/default-jdk/ the standard JDK from Ubuntu Software Center]: {{{ $ sudo apt-get install default-jdk }}} Finally, make sure [http://ant.apache.org/ Ant] and [http://subversion.tigris.org/ Subversion] is installed: {{{ $ sudo apt-get install ant subversion }}} === Setting up an Android project === All data that is to be compiled and packaged into the Android application must be assembled in an Android ''project''. We'll use the template provided by SDL. Download the development snapshot for SDL 1.3 from [http://www.libsdl.org/hg.php this page] to the working directory and then unpack it there, e.g.: {{{ $ cd ~/android $ tar -xvf SDL-1.3.tar.gz }}} Then move the project template to a fitting name under the working directory, e.g.: {{{ $ mv SDL-1.3.0-6172/android-project/ ~/android/0ad }}} This is your ''project directory''. Now move the SDL directory itself into the `jni` directory under the project directory, e.g.: {{{ $ mv SDL-1.3.0-6172/ ~/android/0ad/jni/SDL }}} Then download the game source code into the `jni/src` directory under the project directory, e.g.: {{{ $ svn co http://svn.wildfiregames.com/public/ps/trunk/ ~/android/0ad/jni/src }}} Open the file `Android.mk` in the `jni/src` directory under the project directory in a text editor, e.g.: {{{ $ nano -w ~/android/0ad/jni/src/Android.mk }}} Add the full path of the `jni/src/source` directory to the `LOCAL_C_INCLUDES` declaration, e.g.: {{{ LOCAL_C_INCLUDES := $(LOCAL_PATH)/$(SDL_PATH)/include \ /home/youruser/android/0ad/jni/src/source }}} Add the `source/main.cpp` file to the `LOCAL_SRC_FILES` declaration: {{{ # Add your application source files here... LOCAL_SRC_FILES := $(SDL_PATH)/src/main/android/SDL_android_main.cpp \         source/main.cpp }}} Then save the file and exit the text editor. === Installing replacement libraries === The Android platform provides only a very minimal C++ runtime support library (/system/lib/libstdc++) and corresponding headers for it in the NDK. To compile the game with the Standard C++ Library, we have to explicitly instruct `ndk-build` to compile against the GNU STL runtime. We also have to explicitly enable support for exceptions. Create a new file called `Application.mk` under the `jni` directory in the project directory, e.g.: {{{ $ nano -w ~/android/0ad/jni/Application.mk }}} Insert these three lines in the file, substituting the part after the `:=` on the first line with the full path of your project directory: {{{ APP_PROJECT_PATH := /home/youruser/android/0ad APP_STL := gnustl_static APP_CPPFLAGS += -fexceptions }}} Then save the file and exit the text editor. Download the following libraries to the working directory and then unpack them there: * [http://www.boost.org/users/download/#live Boost] (latest version) * [https://developer.mozilla.org/en/SpiderMonkey/1.8.5 SpiderMonkey] (1.8.5) Move the source code directory of each library into a new directory called `jni/lib` under the project directory, e.g.: {{{ $ cd ~/android $ mkdir 0ad/jni/lib $ mv boost_1_48_0/boost ~/android/0ad/jni/lib/boost $ mv js-1.8.5/js/src ~/android/0ad/jni/lib/js }}} Also copy the SDL source code into the new directory: {{{ $ cp ~/android/0ad/jni/SDL/src ~/android/0ad/jni/lib/SDL }}} Open the file `Android.mk` in the `jni/src` directory under the project directory in a text editor, e.g.: {{{ $ nano -w ~/android/0ad/jni/src/Android.mk }}} Add the full path of the new directory to the `LOCAL_C_INCLUDES` declaration, e.g.: {{{ LOCAL_C_INCLUDES := $(LOCAL_PATH)/$(SDL_PATH)/include \ /home/youruser/android/0ad/jni/src/source \ /home/youruser/android/0ad/jni/lib }}} Then save the file and exit the text editor. Now we must build !SpiderMonkey. Change directory to the !SpiderMonkey source code directory, e.g.: {{{ $ cd ~/android/0ad/jni/lib/js }}} Then execute the following commands to compile !SpiderMonkey as a static library: {{{ $ ./configure --disable-shared-js $ make }}} === Building the application === The native library (i.e. the actual game) is built by running the `ndk-build` command in the project directory, e.g.: {{{ $ cd ~/android/0ad/ $ ~/android/android-ndk-r7/ndk-build }}}