Light Style© by Fisana

Jump to content


Android port


  • Please log in to reply
258 replies to this topic

#21 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 29 December 2011 - 05:05 AM

Don't forget NVTT, Spidermonkey, Enet and fcollada, which are bundled with the source and typically built along with the game. Though depending on how much modification is required, some dependencies could change (for instance, Fam/Gamin is used for monitoring file hotloading which doesn't seem as useful on an Android device).

NVTT - not sure about this one. what does it do?
Spidermonkey - can this be ported to Android's native V8 engine? if not, presumably Spidermonkey has been ported as part of Fennec.
Enet - from a quick check, I see no dependencies outside of libc, so this should compile natively.
fcollada - not sure. this might do it.
  • 0

#22 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,921 posts

Posted 29 December 2011 - 08:42 AM

NVTT does DXTC/S3TC compression of textures at runtime. (We cache pre-compressed textures in releases, but support runtime compression for modders). 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).

We can't use V8 (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; I think the standard releases are meant to work on ARM so that should be okay.

We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work.
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#23 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 29 December 2011 - 09:58 AM

We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work.

Does this customized version have any significant external dependencies?
  • 0

#24 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,921 posts

Posted 29 December 2011 - 10:15 AM

No, just libxml2.
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#25 quantumstate

quantumstate

    Primus Pilus

  • WFG Retired
  • 1,150 posts

Posted 29 December 2011 - 07:59 PM

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.

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.

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.

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.
  • 0

Jonathan Waller [ aka quantumstate ]

Wildfire Games Programmer
Contact me: jonathanmarkwaller at gmail dot com


Support Wildfire Games!


#26 bstempi

bstempi

    Centurio

  • WFG Retired
  • 743 posts

Posted 30 December 2011 - 04:05 AM

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?
  • 0

Brian Stempin [ aka bstempi ]
Wildfire Games Webmaster
Contact me: bstempi@wildfiregames.com

Personal website: brianstempin.com


Support Wildfire Games!


#27 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 30 December 2011 - 05:42 AM

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 this).

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 by afeder, 30 December 2011 - 06:59 AM.

  • 0

#28 gerbilOFdoom

gerbilOFdoom

    Duplicarius

  • WFG Retired
  • 235 posts

Posted 30 December 2011 - 06:21 AM

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.
  • 0

#29 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 05 January 2012 - 04:04 AM

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?
  • 0

#30 historic_bruno

historic_bruno

    Primus Pilus

  • WFG Programming Team
  • 2,390 posts

Posted 05 January 2012 - 07:53 PM

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.
  • 0
Ben Brian [ aka historic_bruno ]

Wildfire Games Programmer
Contact me: ben [at] wildfiregames [dot] com

#31 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 05 January 2012 - 09:05 PM

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?
  • 0

#32 historic_bruno

historic_bruno

    Primus Pilus

  • WFG Programming Team
  • 2,390 posts

Posted 05 January 2012 - 09:41 PM

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.
  • 0
Ben Brian [ aka historic_bruno ]

Wildfire Games Programmer
Contact me: ben [at] wildfiregames [dot] com

#33 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 05 January 2012 - 10:16 PM

Posted Image
  • 0

#34 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 08 January 2012 - 12:00 AM

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.
  • 0

#35 Sonarpulse

Sonarpulse

    Sesquiplicarius

  • Community Members
  • PipPip
  • 166 posts

Posted 09 January 2012 - 09:33 AM

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

Edited by Sonarpulse, 09 January 2012 - 09:33 AM.

  • 0
Posted ImagePosted ImagePosted Image

#36 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 09 January 2012 - 04:26 PM

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.
  • 0

#37 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 10 January 2012 - 03:18 AM

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.
  • 0

#38 historic_bruno

historic_bruno

    Primus Pilus

  • WFG Programming Team
  • 2,390 posts

Posted 10 January 2012 - 04:43 AM

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.
  • 0
Ben Brian [ aka historic_bruno ]

Wildfire Games Programmer
Contact me: ben [at] wildfiregames [dot] com

#39 Sonarpulse

Sonarpulse

    Sesquiplicarius

  • Community Members
  • PipPip
  • 166 posts

Posted 10 January 2012 - 07:22 AM

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.
  • 0
Posted ImagePosted ImagePosted Image

#40 Guest_afeder_*

Guest_afeder_*
  • Guests

Posted 10 January 2012 - 11:26 AM

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 by afeder, 10 January 2012 - 11:46 AM.

  • 0