Android port

[evanssthomas]

Nice to see improvements on the Android build!

I tried building it for my Samsung Galaxy Nexus.

Building using GCC 4.6 resulted in the game crashing at the following line:

/home/crystax/work/ndk/toolchain/build/../gcc/gcc-4.6/libgcc/../gcc/config/arm/linux-atomic-64bit.c:64

So I changed to v4.4.3 (from android-ndk-r8-crystax-1).

The code was using the deprecated field 'unicode' in the struct SDL_Keysym, so I added a dummy entry to the struct to get the game to build.

I also got linking errors in arm.cpp so I changed the method signature from

bool cpu_CAS64(volatile i64* location, i64 expected, i64 newValue)

to

bool cpu_CAS64(volatile intptr_t* location, intptr_t expected, intptr_t newValue)

I built a standard copy of the game and used the following command to create the data archive

binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip -archivebuild-compress

I finally got the game running, but the screen looks weird (Screenshots uploaded), frequently crashes and never goes past the map loading screen. I also get a lot of GL_INVALID_VALUE errors.

Any help would be much apprciated

[Ykkrosh]

Changing cpu_CAS64 to take 32-bit intptr_t arguments probably isn't ideal - there's a reason it has "64" in the name . I think that's only used for some non-critical timer stuff though so it shouldn't really matter.

The screenshot looks like it probably just failed to load any textures. Sounds like Galaxy Nexus is PowerVR - I don't know if anyone has successfully run on that before. (I've used Mali (Galaxy S II) and Adreno (Nexus 7 2013), and historic_bruno has used Videocore (Raspberry Pi).) So it might just be buggy GPU drivers and/or buggy engine code that interacts poorly with those drivers. You should probably make sure it's not trying to use S3TC textures (nos3tc=true in the config file (I assume you've set up the default config file etc already), but I don't think the driver should advertise that extension so it should be disabled automatically anyway), and look in 'adb logcat' for any suspicious error messages, and then try to narrow down the GL_INVALID_VALUE errors to see what's causing them (they may or may not be related to the texture problem, but they should be fixed anyway and they're a place to start) by building in debug mode and adding lots of ogl_WarnIfError() calls until you can see which GL call the error comes from.

[evanssthomas]

Changing cpu_CAS64 to take 32-bit intptr_t arguments probably isn't ideal - there's a reason it has "64" in the name . I think that's only used for some non-critical timer stuff though so it shouldn't really matter.

I realized that but I just wanted to get it to build so I did that

and look in 'adb logcat' for any suspicious error messages, and then try to narrow down the GL_INVALID_VALUE errors to see what's causing them (they may or may not be related to the texture problem, but they should be fixed anyway and they're a place to start) by building in debug mode and adding lots of ogl_WarnIfError() calls until you can see which GL call the error comes from.

They seem to be caused in quite a few places - mostly in GameSetup.cpp (but that's only because Render() calls other drawing functions).

[evanssthomas]

I tried the same build on my friend's Galaxy S3 and the textures get loaded correctly. The map loads and the game starts, but crashes soon after. Has the texture loading failure got anything to do with OpenGL extensions?

The S3's system_info.txt:

Memory         : 832 MiB; 266 MiB freeGraphics Card  : ARM Mali-400 MPOpenGL Drivers : OpenGL ES 2.0; OpenGL OpenGL ES 2.0Video Mode     : 1280x720:32OpenGL Extensions: GL_EXT_debug_markerGL_OES_texture_npotGL_OES_compressed_ETC1_RGB8_textureGL_OES_standard_derivativesGL_OES_EGL_imageGL_OES_depth24GL_ARM_rgba8GL_ARM_mali_shader_binaryGL_OES_depth_textureGL_OES_packed_depth_stencilGL_EXT_texture_format_BGRA8888GL_EXT_blend_minmaxGL_OES_EGL_image_externalGL_OES_EGL_syncGL_OES_rgb8_rgba8GL_EXT_multisampled_render_to_textureGL_EXT_discard_framebuffer 

The Galaxy Nexus's system_info.txt:

Memory         : 694 MiB; 20 MiB freeGraphics Card  : Imagination Technologies PowerVR SGX 540OpenGL Drivers : OpenGL ES 2.0 build 1.8.GOOGLENEXUS.ED945322@2198402; OpenGL OpenGL ES 2.0 build 1.8.GOOGLENEXUS.ED945322@2198402Video Mode     : 1196x720:32OpenGL Extensions: GL_EXT_debug_markerGL_OES_rgb8_rgba8GL_OES_depth24GL_OES_vertex_half_floatGL_OES_texture_floatGL_OES_texture_half_floatGL_OES_element_index_uintGL_OES_mapbufferGL_OES_fragment_precision_highGL_OES_compressed_ETC1_RGB8_textureGL_OES_EGL_imageGL_OES_EGL_image_externalGL_OES_required_internalformatGL_OES_depth_textureGL_OES_get_program_binaryGL_OES_packed_depth_stencilGL_OES_standard_derivativesGL_OES_vertex_array_objectGL_OES_egl_syncGL_EXT_multi_draw_arraysGL_EXT_texture_format_BGRA8888GL_EXT_discard_framebufferGL_EXT_shader_texture_lodGL_IMG_shader_binaryGL_IMG_texture_compression_pvrtcGL_IMG_texture_npotGL_IMG_texture_format_BGRA8888GL_IMG_read_formatGL_IMG_program_binary

[Ykkrosh]

We shouldn't be using any GLES extensions, and as far as I'm aware we aren't. So either I'm mistaken (quite possible), or there's a bug in those PowerVR drivers, or there's a bug in our code.

They seem to be caused in quite a few places - mostly in GameSetup.cpp (but that's only because Render() calls other drawing functions).

The usual approach for debugging GL errors (when there aren't any good tools to help) is to put some ogl_WarnIfError() in randomly, look for the very first error it reports, then look at the region of code between that ogl_WarnIfError and the previous ogl_WarnIfError (which didn't report an error). Then put lots more ogl_WarnIfError() in between those two, and if there are function calls between them, then descend into those functions and put more ogl_WarnIfError there too. Repeat to narrow down the problem further. Eventually you'll end up with an ogl_WarnIfError which doesn't report an error, then a single OpenGL call, then a ogl_WarnIfError which does report an error, and that tells you where the problem. Then print out the arguments that were passed into that GL call, and look at the GLES spec (or ask someone who's familiar with it) to see what's wrong.

[Kwende]

Hi guys, it's the first time I post here, whoever is working on the Android port, it's an awesome initiative! if You need any testers, I have about 10 android devices (including an Ouya) we use at the office for app testing purposes, I wouldn't mind testing on each one of them, I'm not a programmer so I'm gonna try to compile from what I read here and report back my results.

[kirill2485]

I think the controls would fairly easy, and actually very easy if designed for mobile, as seen in this video demonstrating the possibility of running AoK on Windows Phone:

https://www.youtube.com/watch?v=hHuyaa525DA

I would really wanna see it ported on Android.

Edited August 2, 2014 by kirill2485

[kirill2485]

I don't see what a mobile version of 0 A.D. would actually share with the standard desktop/laptop version. I mean the UI, gameplay, and art would need widespread changes to be practical for a mobile device (think bigger, "cuter", simpler, gimmicky) with totally different controls, obviously no keyboard shortcuts or mouse click selection. That means multiplayer between mobile and non-mobile devices wouldn't make sense either, so this idea doesn't make any sense to me at all. A first person shooter is not even remotely comparable, because let's face it, all you have to do is run around, point a gun at your enemies and shoot

no, controls would be fairly easy, as seen in this video:

https://www.youtube.com/watch?v=hHuyaa525DA

[DanCar]

No, but it's not really been a priority. If you're interested in the touchscreen UI being worked on, starting on some mock-ups might give us a little more motivation to begin looking seriously at the idea.

What do you think about an option for the android UI where player controls the AI? In other words the AI controls the game and you control the AI. Ideally there would be an option to turn off and turn on the AI. Either way should be possible to control the units directly as when the AI is off. I can define this further if people like the idea.

[Jaydev]

I don't think launching a reworked version of the same game for lower hardware would be worth it at all. Even if the devs were not to put a price on it, the deeply casual nature of the games on that platform means there won't be much people who would play it there. Everyone who has an Android phone is likely to have a PC as well; and PC is where all RTSs are meant to be.

And how on earth do you play AoE on a phone. That looks mpossible! You'll lose your army trying to run them away, lol.

[Stan`]

Just curious, did anyone get the game running on a phone ?

[Josh]

Just curious, did anyone get the game running on a phone ?

If you read the whole topic, there are pictures of it running on a phone. Somewhere on Philip's server there are also more recent screenshots (<6 months old (?)).

[historic_bruno]

I'm a little curious as to how the game builds on the iPhone SDK.

[andr0id]

Hey guys,

is anyone still working on this? It would be the best RTS for Android.

[historic_bruno]

I'm a little curious as to how the game builds on the iPhone SDK.

Decided to experiment with the iPhone simulator in Xcode, after a bit of work I was able to build an iOS app that runs in the simulator:

This is Xcode 6 on updated OS X 10.9.5, and the simulator is showing iPhone 4s / iOS 8.0. I tried other devices and they mostly work as well, except the Retina-based iPads have incorrect resolution and orientation changes (rotation) corrupt the screen. The Retina issue might be fixed by enabling HiDPI mode in SDL2. When touching a text input box, the onscreen keyboard pops up as shown below, which is nice. Most hotkeys don't work of course. There are some issues with touch input specific to iOS. But I'm quite happy that it works as well as it does

In the coming days, I'll make an ios-support branch on Github, once I have a reasonably stable and cleaned up changeset.

[historic_bruno]

Fixed the orientation problem, it was a bug in our code (incidentally it also affects desktop versions of the game, when the fullscreen resolution changes), and the model_common shader had failed to compile due to a type issue, that is now fixed. The next step will be building for real Apple hardware and ARM, not the i386 simulator.

A slightly more realistic test on a simulated iPad 2, rotated to landscape view:

[feneur]

So in other words, fixing a bug for this experimental version fixed a bug for the usual version of the game? That's a win in my book

[Stan`]

How fast does the game run on an Iphone ?

[historic_bruno]

How fast does the game run on an Iphone ?

I've only tested in the simulator, which isn't useful for performance measurements. I don't own a real iOS device either, so someone else would have to test that

[Stan`]

I got an Iphone 4 working fine except the lock button is broken, How could I test that ?

[historic_bruno]

I got an Iphone 4 working fine except the lock button is broken, How could I test that ?

Well that's the tricky part... I think a 0 A.D. app would never be approved by Apple for relying on GPL code and plus it's a development version and violates all sorts of Apple's app design sensibilities even if they changed the GPL policy. So it can't be distributed through the app store or TestFlight (requires a review for beta apps). Then there are what Apple calls "ad hoc" and "enterprise developer" distribution, they don't require an app review, but only people registered as members of a dev team (for a yearly fee) can install the app and of course there are limits on that. As far as I know, all the official Apple channels require signing the app as a paid developer before it can be installed on a device, even for personal testing.

That basically leaves jailbreaking the device and using a third-party distribution as the only way 0 A.D. could be distributed to non-developers. Cydia is one such service, I don't know anything more about it.

[Stan`]

So... I cannot. I need my lock button to jail break it IIRC.

[Achilles_Kn33]

very interesting