227 replies to this topic

[Ykkrosh]

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.

[Ykkrosh]

No, just libxml2.

[quantumstate]

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.

[bstempi]

gerbilOFdoom, on 26 December 2011 - 09:01 PM, said:

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?

[gerbilOFdoom]

bstempi, on 30 December 2011 - 04:05 AM, said:

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.

[historic_bruno]

afeder, on 05 January 2012 - 04:04 AM, said:

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.

[historic_bruno]

afeder, on 05 January 2012 - 09:05 PM, said:

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.

[Sonarpulse]

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.

[historic_bruno]

afeder, on 10 January 2012 - 03:18 AM, said:

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.