Android port

[bstempi]

Perhaps not a full port, but a mobile add-on that lets a player manage some sort of "global conquest" mode outside of the RTS gameplay? My thought here is like Galactic Conquest from Star Wars Battlefront 2, maybe something like Tribal Wars in terms of functionality. People play the RTS portion of the game on PC, but manage an empire on their mobile device. Just a concept though, I don't have any specific ideas for what it could do at this time.

I don't think I understand this -- I've never played any of the games that you mentioned . Could you elaborate?

[Guest afeder]

I was just looking through your wiki page, it looks interesting, I will be following development of this. I have a few comments about the controls, which I hope you will consider.

First with the map rotation, I think that rotation is a fairly low priority feature so I would suggest using the gesture for another role. I don't know what that would be but I suspect you will be wanting as many easily accessible gestures as you can get since rts games tend to have complicated interaction.

I have changed this so it uses pinch (two-point touch) instead, similar to Google Maps and other applications (like

).

With your selection idea you mention drag select working in two different ways depending on whether the drag started on an entity or not. Having two distinct behaviors for the same action seems like an idea which is bound to cause annoyance, especially since units are probably going to be fairly small. I would definitely suggest choosing one of them and being consistent (I personally prefer box select). Another selection idea is to have a selection brush (see halo wars) where you swipe and everything near your stroke gets selected.

I've changed this so it does bounding box (only), while panning slowly. On PC, you can hold the mouse button and drag the mouse an infinitely (in principle) long way. You can't do this on touch screen, because you have to release the touch when you reach the edge of the screen. This 'panning mode' is intended to solve that.

If you haven't already I would suggest taking a look at halo wars with its simplified console controls and the C&C series which had single button mouse controls.

'Selection brush' also seems like a pretty good idea, if a convenient brush size can be found and control groups are easy to manage (so you don't need to brush over and over again.)

For giving units commands I would have a single click do the units primary action (context sensitive, what the main game does on right click) and them have a held click bring up a circular action chooser again context specific, e.g. attack move, building construction, garrison. The problem with this is that you lose the selection controls. To get round this you would need an easily accessible clear selection command, this could be done with a simple gesture or having a dedicated button. This would be the most frequent action in the game so would need to be very quick.

For primary action, I propose double tap. I agree that selection preferably should be done with some of the fastest gestures, though I'm not sure how, without destroying the panning controls.

Maybe there could be a modifier button (since the target device supports multi-touch): if you hold the button, swiping does camera panning, if you don't hold the button, swiping does bounding box selection. Additionally, swiping on the button itself could do panning, for simple panning back and forth in the local vicinity.

Edited December 30, 2011 by afeder

[gerbilOFdoom]

I don't think I understand this -- I've never played any of the games that you mentioned . Could you elaborate?

What I mean is, instead of a complete port of the game, a separate game that integrates into the standard 0 AD gameplay. I'm thinking a persistent world in which players build up an "empire" in a tick-based strategy game with combat either happening on the desktop or through "dice rolls", depending on the choice of the players involved. The players could even assign bots to run the combat for them. When I say combat, I mean the normal 0 AD gameplay. When players attack from the mobile version, the units they attack with are converted to additional starting units in the desktop version for the corresponding battle (as are the defender's units). If time zone discrepancies exist, the player would probably choose to revert to dice rolls, bots, or having someone else run the battle for them. It would be far less work than completely porting the game, could be set up using HTTP services (web browser access as well as mobile app access), and would still add an interesting new dynamic in the form of a persistent game world. I can see the politics of the persistent world becoming fairly intense.

[Guest afeder]

So, I've been looking through the NDK documentation, trying to figure out how all this would work. Apparently, the native code (e.g. the Pyrogenesis engine) will be compiled as a shared library which can then be invoked from an Android application. From the Android application we can access the standard Android APIs for e.g. touch interfaces. So I imagine the Android application will register e.g. gestures and pass them on to the game engine as function calls to the shared library.

This raises the question of how the game engine should respond to these events. As far as I understand from the wiki, handlers for other 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.

If this is a possibility, can I work with you to specify the new events and have them implemented (eventually) in the engine's main codebase?

[historic_bruno]

This raises the question of how the game engine should respond to these events. As far as I understand from the wiki, handlers for other 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.

If this is a possibility, can I work with you to specify the new events and have them implemented (eventually) in the engine's main codebase?

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.

[Guest afeder]

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.

There does indeed seem to be a set of functions for gestures which are probably the most crucial type of input events. Despite the mess, can you give me some pointers to where approximately the code for capturing these events should be added?

[historic_bruno]

There does indeed seem to be a set of functions for gestures which are probably the most crucial type of input events. Despite the mess, can you give me some pointers to where approximately the code for capturing these events should be added?

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.

[Guest afeder]

[Guest afeder]

I've added the build instructions so far to the wiki. If anyone wants to help out they can follow the instructions, see what errors the ndk-build tool generates, and suggest solutions.

[Sonarpulse]

Can Android tablets use an external keyboard and mouse? That might be a good starting point for this.

Edited January 9, 2012 by Sonarpulse

[Guest afeder]

Can Android tablets use an external keyboard and mouse? That might be a good starting point for this.

Android supposedly supports external input devices since version 3.1 (Honeycomb), but I don't know if it is supported in SDL yet.

[Guest afeder]

Here are two build errors I'm currently looking at:

In file included from /home/afeder/android/0ad/jni/src/source/main.cpp:41:

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:37:22: error: SDL/SDL.h: No such file or directory

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:38:29: error: SDL/SDL_thread.h: No such file or directory

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:44:29: error: SDL/SDL_endian.h: No such file or directory

Why are these files included from a directory named SDL? In my copy of SDL (1.3), they reside in $(SDL_PATH)/include.

In file included from /home/afeder/android/0ad/jni/src/source/lib/file/io/io.h:37,

from /home/afeder/android/0ad/jni/src/source/ps/Filesystem.h:22,

from /home/afeder/android/0ad/jni/src/source/main.cpp:46:

/home/afeder/android/0ad/jni/src/source/lib/posix/posix_aio.h:31:18: error: aio.h: No such file or directory

Is POSIX asynchronous IO (AIO) used for anything important in the game? It does not immediately seem to be supported on Android.

[historic_bruno]

Here are two build errors I'm currently looking at:

In file included from /home/afeder/android/0ad/jni/src/source/main.cpp:41:

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:37:22: error: SDL/SDL.h: No such file or directory

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:38:29: error: SDL/SDL_thread.h: No such file or directory

/home/afeder/android/0ad/jni/src/source/lib/external_libraries/sdl.h:44:29: error: SDL/SDL_endian.h: No such file or directory

Why are these files included from a directory named SDL? In my copy of SDL (1.3), they reside in $(SDL_PATH)/include.

That's because libraries/sdl/include gets added to the include search path, I guess so we have consistency on all platforms. One solution is to copy the SDL 1.3 includes to a new directory that has the expected SDL/SDL*.h structure, and make sure you add it to the search path.

[Sonarpulse]

AFIAK SDL 1.2 just comes sdl/lib etc hierarchy for convenient packaging. In most scenarios one would end up using a lib/sdl etc hierarchy and likewise doing "#include <SDL/SDL.h>". Most sdl programs I have seen also use that c directive, or the equivalent with quotes if SDL is stored with the project to avoid version errors. I can't see why android should be any different.

[Guest afeder]

AFIAK SDL 1.2 just comes sdl/lib etc hierarchy for convenient packaging. In most scenarios one would end up using a lib/sdl etc hierarchy and likewise doing "#include <SDL/SDL.h>". Most sdl programs I have seen also use that c directive, or the equivalent with quotes if SDL is stored with the project to avoid version errors. I can't see why android should be any different.

Is there some kind of trick I am missing for 'aliasing' SDL/include as SDL when compiling? I could use symbolic links, but that seems a bit odd.

If not, I'll have to copy the directory as historic_bruno suggested, since the Android-specific makefiles that SDL provides expects SDL/include, e.g. this one:

SDL_PATH := ../SDL

LOCAL_C_INCLUDES := $(LOCAL_PATH)/$(SDL_PATH)/include

Edited January 10, 2012 by afeder

[Sonarpulse]

That's weird. How mature is the android port, it might be an idiosyncrasy of the developers, maybe it's this way to allow easy testing of multiple versions of SDL.

[Guest afeder]

That's weird. How mature is the android port, it might be an idiosyncrasy of the developers, maybe it's this way to allow easy testing of multiple versions of SDL.

Indeed, the Android port is only available with SDL 1.3 which is not yet stable.

[Guest afeder]

So far, I've been able to get ndk-build to compile the game with SDL, Boost and SpiderMonkey. I am now down to this error output:

http://pastebin.ca/2102027

The OpenGL errors are to be expected, but I am not quite sure how to proceed with the others. Hints appreciated.

[historic_bruno]

So far, I've been able to get ndk-build to compile the game with SDL, Boost and SpiderMonkey. I am now down to this error output:

http://pastebin.ca/2102027

You don't have std::wstring, quick research led to conflicting suggestions as to whether it's possible to use wstring with NDK.

[Guest afeder]

You don't have std::wstring, quick research led to conflicting suggestions as to whether it's possible to use wstring with NDK.

Indeed, std::wstring appears not to be supported by the official NDK. Seems I have to use the Crystax NDK.

[Ykkrosh]

I committed some changes to allow building with SDL 1.3 (at least on Linux), though it doesn't actually run correctly (the window size is bogus). Also you can run "SDL_CONFIG=$HOME/local/bin/sdl-config ./update-workspaces.sh" etc if you want to point it to a locally-installed copy of SDL, instead of using whatever the default sdl-config points to.

About OpenGL ES: Don't remember whether I've mentioned this before, but if not: 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.

[Guest afeder]

Thanks

[Ykkrosh]

About OpenGL ES: On Linux you can compile Mesa with GLES support (on Gentoo you just do "USE=gles emerge mesa"), and I added some stuff so you can run "./update-workspaces.sh --gles" and build the game and get a zillion errors. I fixed errors in lib/ (except for ogl_shader.cpp which should be deleted once CShaderManager supports GLSL), mostly by #if'ing out the problematic things (since the rest of the game still depends on things that GLES doesn't support - should fix that later). Then I got bored - I'm not planning to make this actually work properly in practice, but hopefully it's a step in the right direction

[Guest afeder]

Very good I am now down to this error output, using Crystax NDK and the CONFIG2_GLES flag with the latest source.

[Guest afeder]

I managed to get rid of most of the errors with assert.h by defining BOOST_DISABLE_ASSERTS. Is this an acceptable solution or is there some reason that Boost's assertion stuff is enabled?