Can I help with Android port?

[bog_dan_ro]

Hello, I have quite a lot experience in porting C++ projects to Android (I'm the original author of Qt port to Android).

What I can help with:

- update the Android Activity and create new project files which will be used by a decent IDE. We'll need them for debugging the C++ part on Android.

- compile the project + dependencies for Android, here I have an idea which will cut most of the dependencies.

- game editor on Android?

What I can't help with:

- port GL part to GLES2. I have (almost) no experience on that area.

Please let me know if I can help you on this matter.

[Itms]

Hi bog_dan_ro, and welcome

If you want to help with Android ports, that's great! We're not expecting to be able to deliver an amazing user experience on embedded systems, mainly because of performance problems, but updating the Android activity definitely sounds like a good idea.

Don't hesitate to connect to #0ad-dev on QuakeNet to discuss with people and get some help, and you can take a look at all the information on our wiki/bug tracker to get you started: GettingStartedProgrammers

We're also open to suggestions, if you encounter problems.

Good luck, and have fun

[thamlett]

Wow, this would be amazing. If you need help, I have a recent Android device ( HTC one) that can be used for testing.

[bog_dan_ro]

Thanks a lot Itms for the welcome!

Well, we can't compare android devices graphics cards with ATI/NVIDIA dedicated graphics cards , but I think some of them are quite close to Intel (or even better). So if 0AD works well on my laptop (with an Intel graphics card) I think it will work just fine on Android too. Of course I'm not expecting it will work on low-end devices, but I'm expecting to work quite well on high-end devices.

Thanks a lot Thamlett! I have some (quite powerful) devices that I can use for developing.

I think I need to fill the WFG Application form .

Position:

Programmer (mostly Android port).

Do you understand that Wildfire Games is a non-commercial project, work for 0 A.D. is volunteer, and work is done for free?
Yes

Do you agree to distribute all your work for Wildfire Games under Creative Commons Attribution Share-Alike license?
Yes

Name:
BogDan

Email:
bog_dan_ro@yahoo.com

Location:
Brasov, Romania (Eastern Europe).

Availability:
It depends ... I hope more than 5h/w

Age:
34

Occupation:
Working

Skills and Experience:
I have +10y of C/C++ experience and for this job I'd like to mention that I'm the original author of Qt port on Android, and the Android platform maintainer[1].

Motivation:
I love to code and I love free software.

Personality:
Dreamer.

Short Essay:
I read about 0AD a few years ago (I don't remember exactly where).

What motivates me to be a part of the project? I like a lot this game, I believe in free software and I'd like to have it on Android .

What do I seek to gain in being a part of Wildfire Games? Besides that I want to be able to play WFG games on my tablet/phone, nothing in particular, I'm an altruist .

Interests and Hobbies:
Play games with my son, swiming, coding, go to movies, listen music, etc.

Staff:

-

Community:
-

Favorite Game:
I like a lot of games, besides 0AD , I love to play Settlers II 10th Aniversary, Settlers III, Children of the Nile (by far my favorite city builder), Caesar III, Pharaoh, Zeus and Poseidon, etc.

Work Examples:
- https://necessitas.kde.org

- http://doc-snapshot.qt-project.org/qt5-5.4/android-support.html

- http://doc-snapshot.qt-project.org/qtcreator-3.3/creator-deploying-android.html

[1] http://qt-project.org/wiki/Maintainers#7d2771598d28e6c832435c469bb17c86

[Lion.Kanzen]

Thanks a lot Itms for the welcome!

Well, we can't compare android devices graphics cards with ATI/NVIDIA dedicated graphics cards , but I think some of them are quite close to the Intel (or even better). So if 0AD works well on my laptop (with an Intel graphics card) I think it will work just fine on Android too. Of course I'm not expecting it will work on low-end devices, but I'm expecting to work quite well on high-end devices.

Thanks a lot Thamlett! I have some (quite powerful) devices that I can use for developing.

I think I need to fill the WFG Application form .

Position:

Programmer (mostly Android port).Do you understand that Wildfire Games is a non-commercial project, work for 0 A.D. is volunteer, and work is done for free?YesDo you agree to distribute all your work for Wildfire Games under Creative Commons Attribution Share-Alike license?YesName:BogDan

Email:bog_dan_ro@yahoo.com

Location:Brasov, Romania (Eastern Europe).

Availability:It depends ... I hope more than 5h/w

Age:34

Occupation:WorkingSkills and Experience:I have +10y of C/C++ experience and for this job I'd like to mention that I'm the original author of Qt port on Android, and the Android platform maintainer[1].Motivation:I love to code and I love free software.

Personality:Dreamer.Short Essay:I read about 0AD a few years ago (I don't remember exactly where).

What motivates me to be a part of the project? I like a lot this game, I believe in free software and I'd like to have it on Android .

What do I seek to gain in being a part of Wildfire Games? Besides that I want to be able to play WFG games on my tablet/phone, nothing in particular, I'm an altruist .

Interests and Hobbies:Play games with my son, swiming, coding, go to movies, listen music, etc.Staff:

-

Community:[i

I'm not sure but this info need be in posted in properly forum as new topic form Edited December 23, 2014 by Lion.Kanzen

[Itms]

The application form is not needed for programmers anyways

[bog_dan_ro]

Ah, I didn't know that programmers don't need to fill the application form .

Anyway, let's get back to the problem . This are the steps that I'd like to take for the Android port:

• I'd like to use QtCreator as IDE. QtCreator is a great cross-platform IDE and I choose it because it has a great support for C/C++ and also for Android. Regarding the build system, I'd like to use the brand new qbs [1], for a few reasons: it is well supported by QtCreator, and the (upcoming) Android support is great!

• The next step is to decide what to do with the dependencies, I see two solutions here:

1. add all dependencies to the project tree (all their sources) and compile all of them for Android. Personally, I don't like this approach at all, because it takes a lot of time to "port" all dependencies to Android (make them compile) and it pollutes Pyrogenesis' source tree.
2. at first look Qt has support for (almost) all Pyrogenesis' dependencies (image formats, xml, networking, etc.), so I'd like to make all dependencies optional and use Qt instead on Android. Qt 5 on Android is quite stable.

• Atlas: after first two steps are complete, I'd like to focus on the game editor. I propose to rewrite the UI in Qt Quick Controls [2]. Qt Quick Controls are great because they look and feel native on all supported platforms[3] (which AFAIK are quite more than wxWidgets supported platforms) not only on Android[4]. A big plus of QQC is that they are touch friendly, so we don't need to create another UI for mobile devices. They are also very easy to use, so anyone can contribute and maintain it.

[1] http://doc-snapshot.qt-project.org/qbs

[2] http://doc-snapshot.qt-project.org/qt5-5.4/qtquickcontrols-index.html

[3] http://doc-snapshot.qt-project.org/qt5-5.4/supported-platforms.html

[4] http://blog.qt.digia.com/blog/2014/12/03/native-android-style-in-qt-5-4/

[fabio]

Hi and welcome!

There is already some form of Android support, you may want to have a look at these two resources: 0 A.D. Android port forum thread and 0 A.D. Android port wiki page.

[Itms]

The changes you propose sound super-heavy, and we wouldn't choose to spend time on these only to ease Android porting, because we already have much work to do on the game itself!

The developers made a handful of choices across the years and now that things are settled it is better to avoid complete turnabouts. On top of that, the Android port should be more or less working already, the only missing thing is an active development of it.

But of course, no one will prevent you from working on a way to use QtCreator as IDE, and so on. Having more toolchains available for contributors can be very interesting.

[bog_dan_ro]

Hi and welcome!

There is already some form of Android support, you may want to have a look at these two resources: 0 A.D. Android port forum thread and 0 A.D. Android port wiki page.

Hi Fabio,

I've seen it ... but is quite hard to maintain or contribute, and no debugging (well, at least not easy and not from the first line).

I prefer to spend more time now to prepare an easy to use development environment for Android, then to spend much longer time hunting bugs using the logs .

The changes you propose sound super-heavy, and we wouldn't choose to spend time on these only to ease Android porting, because we already have much work to do on the game itself!

The developers made a handful of choices across the years and now that things are settled it is better to avoid complete turnabouts. On top of that, the Android port should be more or less working already, the only missing thing is an active development of it.

But of course, no one will prevent you from working on a way to use QtCreator as IDE, and so on. Having more toolchains available for contributors can be very interesting.

They sound super-heavy, but they are not that heavy . I don't want you to spend any time to do changes, I can do them myself. I just want to make sure developers will be open to discuss and check the patches for Android, because the last thing on earth I want, is to maintain them by myself in a separate place .

I don't want to replace or to change the existing things, the old stuff will work as it worked before (e.g. the people can still use premake, etc.). I just need to add a layer where the engine uses these dependencies directly. I'll try to keep these changes minimal.

All these changes are needed because if you want Android to be a first class citizen platform for Pyrogenesis then we'll need and easy way to develop&debug Pyrogenesis on Android, and I'm afraid there is no other (easier) way to do it ...

[leper]

• add all dependencies to the project tree (all their sources) and compile all of them for Android. Personally, I don't like this approach at all, because it takes a lot of time to "port" all dependencies to Android (make them compile) and it pollutes Pyrogenesis' source tree.

Use a script to fetch dependencies and build them, see http://trac.wildfiregames.com/browser/ps/trunk/libraries/osx or even better http://trac.wildfiregames.com/browser/ps/trunk/build/android.

• at first look Qt has support for (almost) all Pyrogenesis' dependencies (image formats, xml, networking, etc.), so I'd like to make all dependencies optional and use Qt instead on Android. Qt 5 on Android is quite stable.

All these changes are needed because if you want Android to be a first class citizen platform for Pyrogenesis then we'll need and easy way to develop&debug Pyrogenesis on Android, and I'm afraid there is no other (easier) way to do it ...

Breaking network compatibility and calling it a first class citizen is not the way it works.

The real changes needed to make the Android port anything more than a proof-of-concept is someone working on a usable user interface.

• Atlas: after first two steps are complete, I'd like to focus on the game editor. I propose to rewrite the UI in Qt Quick Controls %5B2%5D. Qt Quick Controls are great because they look and feel native on all supported platforms%5B3%5D (which AFAIK are quite more than wxWidgets supported platforms) not only on Android%5B4%5D. A big plus of QQC is that they are touch friendly, so we don't need to create another UI for mobile devices. They are also very easy to use, so anyone can contribute and maintain it.

Supporting the editor on Android seems a bit strange for a platform where sharing the maps you created without any other tools will be a bit cumbersome. Nobody who wanted to rewrite Atlas (you're not the first) produced anything working, or pointed out a lot of things that were broken and not fixable without a complete rewrite (not that Atlas is without issues). If someone is actively going to work on something that big having an idea of what does not work now is a huge part of not introducing those bugs again, and that does not guarantee that no new bugs will be there.

They sound super-heavy, but they are not that heavy . I don't want you to spend any time to do changes, I can do them myself. I just want to make sure developers will be open to discuss and check the patches for Android, because the last thing on earth I want, is to maintain them by myself in a separate place .

I don't want to replace or to change the existing things, the old stuff will work as it worked before (e.g. the people can still use premake, etc.). I just need to add a layer where the engine uses these dependencies directly. I'll try to keep these changes minimal.

Patches that replace huge parts of the engine just for one platform and the sake of it and make that platform incompatible with the rest of the game are very likely not going to be accepted.

[bog_dan_ro]

Hello folks,

I have some good news on this matter. I managed to:

- compile all dependencies (I upload the precompiled dependencies to https://dl.dropboxusercontent.com/u/67435935/0AD/android.tar.bz2 , untar it in 0ad/libraries).

- fix compilation for Android

- create new project files which can be used from QtCreator to manage, compile, deploy, run & *debug* on any Android Device (open 0ad/build/android/qtcreator/qtcreator.pro in QtCreator and choose an Android Qt 5.4 KIT).

What doesn't work:

- the old way to compile for android, didn't had time to fix premake files for Android.

- the game the UI is completely screwed ...

- I had to disable the audio because it crashes.

I upload the patches to https://github.com/bog-dan-ro/0ad (I'll upstream all patches as soon as I'm happy with their status).

Use a script to fetch dependencies and build them, see http://trac.wildfiregames.com/browser/ps/trunk/libraries/osx or even better http://trac.wildfiregames.com/browser/ps/trunk/build/android.

All right, I updated android script. Now it compiles & installs all project dependencies.

Breaking network compatibility and calling it a first class citizen is not the way it works.

HUH ?!?! what makes you believe that using another library for networking it will break its compatibility? The protocol is the same, it's just another library ...

Anyway, I'll stick with current dependencies .

The real changes needed to make the Android port anything more than a proof-of-concept is someone working on a usable user interface.

Yep, but having an easy way to deploy, run & debug the application on Android will speed up the development.

Supporting the editor on Android seems a bit strange for a platform where sharing the maps you created without any other tools will be a bit cumbersome.

It's not strange at all. You create a map and save it on the sd_card. There are lots of ways to share the map, much more than you have on your desktop . It's so easy to start an Intent which share the map via any service which allows attachments: mail, bluetooth, dropbox, gdrive, etc.

It will be nice if if the future the users will be able to share the maps directly from Atlas, e.g. a market (a small RESTfull webservice) which can be used by the games to upload & share their maps.

I think the real challenge will be to create a touch friendly UI ...

Nobody who wanted to rewrite Atlas (you're not the first) produced anything working, or pointed out a lot of things that were broken and not fixable without a complete rewrite (not that Atlas is without issues). If someone is actively going to work on something that big having an idea of what does not work now is a huge part of not introducing those bugs again, and that does not guarantee that no new bugs will be there.

As I said before this is the last step ;-). I know it is a big task, it will help a lot if there is a list with the things that works and those that don't.

Edited December 26, 2014 by bog_dan_ro

[leper]

I upload the patches to https://github.com/bog-dan-ro/0ad (I'll upstream all patches as soon as I'm happy with their status).

The sprintf_s could be fixed by including lib/secure_crt.h instead.

g_XmppClient is defined and set to NULL if you build without the lobby (at least when using premake, so your build system is broken).

You should use OS_ANDROID in cases where you have different ifdefs.

The changes to lib/config2.h should go into some build script or project file.

HUH ?!?! what makes you believe that using another library for networking it will break its compatibility? The protocol is the same, it's just another library ...

Unless you implement ENet 1.3's protocol with that library you will not be able to play multiplayer.

Seems like a good start

[bog_dan_ro]

Status update:

- The UI seems to be ok now : check this image (yep the FPS is very low because I'm using a debug build).

- I tried it also on release but it crashes ...

Next steps:

- I'll need some help to fix the GL errors.

- fix the crash in release mode.

- I'll try again to enable and fix the sound.

- move the game data to an OBB file.

Does anyone knows if and how I can set the DPI? The text and the controls are very small and quite unusable.

interestinglog.html

ERROR: CRenderer::EndFrame: GL errors 1280 occurred
ERROR:
ERROR: GUI page 'page_gamesetup.xml': Failed to call init() function

I also have tones of:

W/pyrogenesis(27096): GL_INVALID_OPERATION
W/pyrogenesis(27096): 000000 p=0.465000
W/pyrogenesis(27096): 5000
W/pyrogenesis(27096):
W/pyrogenesis(27096): 502
W/pyrogenesis(27096): ----------------------
W/pyrogenesis(27096): OpenGL error(s) occurred: 0502
W/pyrogenesis(27096): 000

Most probably one of the reason(s) of the slowness ...

Edited December 27, 2014 by bog_dan_ro

[bog_dan_ro]

The sprintf_s could be fixed by including lib/secure_crt.h instead.

I tried but for some reason it fails, is there any reason why you prefer to use sprintf_s instead of snprintf ?

g_XmppClient is defined and set to NULL if you build without the lobby (at least when using premake, so your build system is broken).

g_XmppClient is defined in source/lobby/Globals.cpp and I didn't add it to my build system. Anyway I'll try to enable lobby for android and I'll revert that patch.

You should use OS_ANDROID in cases where you have different ifdefs.

Done.

The changes to lib/config2.h should go into some build script or project file.

[...]

Seems like a good start

Got it, I'll keep them for a while until I'll fix the most important errors first.

Thanks!

[Stan`]

interestinglog.html

ERROR: CRenderer::EndFrame: GL errors 1280 occurred

ERROR:

We are having that 1280 GL error on windows too. I have it when I load too much buildings at the same time. Maybe a memory problem.

[thamlett]

http://stackoverflow.com/questions/16743914/opengl-es-2-0-teximage2d-giving-error-1280

Apparently we're not the only ones to have the problem lol

You got a GL_INVALID_ENUM error, which means you passed an unsupported enum value to a GL function. The 1280 is GL_INVALID_ENUM, but 1285 would be the GL OUT OF MEMORY error.

[bog_dan_ro]

Folks I have great and also quite bad news on this matter

Let's start with the good news:

- I managed to enable all Pyrogenesis' features (audio, lobby, etc.). The sound sounds great ;-).

- I fixed all the visible crashes, there were two problems:

1. vswprintf is quite crappy on Android. It don't support %hs and %ls and it also don't add \0 at the end of the string in the output buffer . This was the root cause for sound crash

2. In XeroXMB there were some places where it reads unaligned memory, which on ARM will cause an SIGBUS in release mode.

- The UI looks great!

Now the bad news:

- Even in Release mode the game performs terrible 5-10 FPS . The UI is quite acceptable (~30 FPS) though.

- After the game starts I see GL_INVALID_OPERATION (0x502) error on every frame.

- It seems to have massive memleak, after the game starts it eats more and more memory until it gets killed by the OS. My hunch is that the memleak is caused by GL_INVALID_OPERATION, because every time I see it it eats more memory ...

Here you can find the log from the device.

Can anyone me with GL_INVALID_OPERATION problem? Sadly my GL skills are closed to 0 (B.C. ). Now it is so easy to develop & debug on Android !

BTW I'd like to update the Android wiki page with the new stuff, do I need special permissions? Is there anyone who does this job?

[Lion.Kanzen]

...BTW I'd like to update the Android wiki page with the new stuff, do I need special permissions? ...

No you dont need it.

[feneur]

BTW I'd like to update the Android wiki page with the new stuff, do I need special permissions? Is there anyone who does this job?

You just need to register and be logged in And the wiki is meant to be updated by anyone who has got something useful to write there So please go ahead and keep improving it when you do have something new to add/update

[niektb]

[...]

Now the bad news:

- Even in Release mode the game performs terrible 5-10 FPS . The UI is quite acceptable (~30 FPS) though.

The UI normally runs at >200 FPS

[fabio]

Great news

You may want to upgrade libxml2 to 2.9.2, it fixes many leaks, probably not the ones that make the game crash.

Which device are you using? How much RAM does it have? Maybe it's just too few for 0 A.D.. Also some Android graphics drivers are known to be buggy.

[fabio]

Also you may try forcing a lower resolution than the screen native one and disable some graphics features that may trigger the problem.

[fabio]

Hi, do you have any news on Android port progress?

[bog_dan_ro]

Hi!

I slowdown the development a little bit because of the GLES errors, and I focused on an easy way to "debug" the GPU on Android. I tried different tools (which none of them worked as I expected) and I end up using apitrace. But even with apitrace it wasn't perfect because it does the retrace on desktop and the GLES implementations are quite different, and I didn't get the same errors on Desktop. So I had to find a way to do the retrace on Android .... This way I end up working on an apitrace retracer for Android .

The good new are that I managed to finish the retracer and also I integrate it in the UI . Last night I created the pull request ( https://github.com/apitrace/apitrace/pull/311 ).

I need someone who knows GL(ES), to help me to fix these errors and also to check/debug the trace(s) to see why it eats that much memory (+1Gb), the problem is that when the game starts, it eats more and more memory until its killed by the OS . At the beginning I suspect the engine has some leaks, that why it continuously eats memory, but I've seen the same thing happens with the retracer on Android, so now I suspect that the GL(ES) commands, somehow are responsible for the leaks. Even more, having an application that can replay the trace directly on Android, its great because I could run also benchmarks and it seems that not the CPU is the (main) bottleneck for the slowness, but the GPU. There are frames that have +10k of GL commands, which it seems is a little bit too much for an android tablet

Anyway, I hope this weekend to have time to update the Android wiki page, this way anybody will be able to build, run & debug pyrogenesis on Android. Also I need to check what are the steps to upstream my 0 A.D. work ;-).

Apart that someone needs to make the UI touch friendly, the only "major" task that *I* need to do, is to bundle game data in an OBB, make sure that OBB is downloaded together with the game, mount it, set the game data paths to the mount location, and then we can start publishing it on Google Play! BTW does wildfiregames have an official Google Play account?