Jump to content

Android port


Guest afeder
 Share

Recommended Posts

It is possible to sell it, but it is not possible to prevent people from freely redistributing it. So someone could buy it and then offer it for free to everyone else.

There are many ways to workaround this:

  1. change the license to Android specific code to a non-free one, forbidding redistribution (obviously one can rewrite this code);
  2. trademark "wildfiregames" or "0 A.D." and forbids its use on Android Market (the code is still free, but cannot be distributed as 0 A.D. (see Red Hat and its clones));
  3. just link from the 0ad web page the sponsored 0 A.D. Android App, asking to buy it for supporting development rather than downloading it for free;
  4. provide some plus service other than the game binary (let's suppose you can, for example, submit your game score to a central server comparing to other players...);

That being said what I like most about 0 A.D. is the fact it is free (according to the FSF) and for sure I wouldn't be interested in it otherwise, but anyway it would be nice if developers can find a way to sponsor its development.

Link to comment
Share on other sites

@abio: The program steps are too complicated, this game has always been free, and unnecessarily so. Thank you!:banger::victory:dry.gif

@Ykkrosh :The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you!:unsure:

Edited by gameboy
Link to comment
Share on other sites

Rough usage instructions:

"hg clone http://hg.libsdl.org/SDL" into build/android/sdl-project/jni/ (or clone elsewhere and symlink it there, or whatever). Until this bug is fixed, apply the patch from there.

In build/android/sdl-project/, run "make". That should compile SDL and the .apk file. (Dependency checking is probably broken, so run "make clean" if you need to rebuild after changing stuff.)

In build/android/, run "./setup-libs.sh". The script hardcodes the expected locations of NDK and SDK, so put them there or adjust the script, and it will output to ~/android/toolchain-0ad. That should download and compile loads of stuff.

Build the game like


./update-workspaces.sh --gles --android --without-fam --without-audio --disable-atlas --with-system-mozjs185 --with-system-enet --with-system-nvtt --without-nvtt

and


TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/ -I../../android/files/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug

Then attach a device, and in build/android/sdl-project/ run "make push-apk" and "make push-so". Run /sdcard/0ad.apk on the device to install. Then you need to build a public.zip containing all the data files, kind of like what source/tools/dist/build.sh does, and preferably unzip+zip it so that it's compressed properly (to save bandwidth and space), and push to /sdcard/0ad/data/mods/public/public.zip, then run the app.

Hi Philip,

I've followed the instructions as such and everything completed successfully except libpng where setup-libs.sh downloads libpng-1.5.8.tar.xz but tries to unpack libpng-1.5.7.tar.xz. I changed that in the setup-libs.sh script.

when I run make push-so, I get the following error. Apparently libpyrogenesis_dbg is not getting created. Any idea why?


cp ../../../binaries/system/libpyrogenesis_dbg.so libs/armeabi/
cp: cannot stat `../../../binaries/system/libpyrogenesis_dbg.so': No such file or directory
make: *** [push-so] Error 1

Great effort on the Android port, by the way!

Evans

Link to comment
Share on other sites

The build was actually not completing successfully. I somehow failed to notice that.


TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/ -I../../android/files/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug

In the above line, I had to change -I../../android/files/SDL/include to -I../../android/sdl-project/jni/SDL/include/ to get it to work.

Then you need to build a public.zip containing all the data files, kind of like what source/tools/dist/build.sh does, and preferably unzip+zip it so that it's compressed properly (to save bandwidth and space), and push to /sdcard/0ad/data/mods/public/public.zip, then run the app.

Zipping up the contents of ~/0ad/binaries/data/mods/public and pushing it to my SD card did not work. If you could let me know specifically what files need to be in the zip file, that would be great.

Thanks

Edited by evanssthomas
Link to comment
Share on other sites

I've followed the instructions as such and everything completed successfully except libpng where setup-libs.sh downloads libpng-1.5.8.tar.xz but tries to unpack libpng-1.5.7.tar.xz.

Oops, fixed now. (Also I slightly cleaned up and committed some earlier changes that I'd used to get the game launching, though I haven't tested the current code on Android yet.)

Zipping up the contents of ~/0ad/binaries/data/mods/public and pushing it to my SD card did not work. If you could let me know specifically what files need to be in the zip file, that would be great.

You need to use the game engine to create the zip, since it has to convert all the textures/models/animations/etc into a different format before zipping them up. Build a standard non-Android copy of the game, then run like "binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip" and it should print lots of output and will take a while (maybe ten minutes or more). Then (optionally) extract that ~700MB public.zip into a new directory and zip it all up again so that it's properly compressed to ~300MB. Then copy to /sdcard/0ad/data/mods/public/public.zip and the game should see it. (If you want to change a few data files after that, you don't need to regenerate public.zip - just copy the individual files straight into mods/public/ and they'll override the zipped version.)

Also, copy binaries/data/config/default.cfg into /sdcard/0ad/appdata/config/.

Hopefully that's about enough, but I might be forgetting things. The game's log messages are visible through "adb logcat" so that should indicate when things are going wrong.

Link to comment
Share on other sites

This looks a lot of trouble to compile another better way? More simple methods of compiling, thank you!:banger:

@historic_bruno's :The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you

Edited by gameboy
Link to comment
Share on other sites

By the way, I noticed a significant speed improvement when reading PDF files by simply moving them off the SD card to internal storage. Depending on the class of SD card you are using, this will likely hold true.

As far as I'm aware, /sdcard is not an SD card - it's just a partition of the standard built-in Flash storage. (The SGS2 apparently has 16GB of storage, split into ~2GiB of "device memory" for applications, 11.5GiB of "USB storage" for data or large applications, and presumably ~2GiB for system stuff). (The optional external SD card gets mounted into /sdcard/external_sd instead). So I think in theory it shouldn't make a difference on this device, though I've never tested it. Since loading performance isn't too bad anyway (and I'd suspect it's mostly CPU-bound), and the "device memory" is pretty small, and it's hard to upload/download files to device memory (I think the only way is 'adb push' to /data/data/local/, and the USB connection is much slower than copying with SFTP over wifi), it doesn't seem worth the effort to me :)

This looks a lot of trouble to compile another better way? More simple methods of compiling, thank you!:banger:

This is an experimental prototype for developers - if you don't understand the instructions, it's probably not for you :P

Link to comment
Share on other sites

(Also I slightly cleaned up and committed some earlier changes [...])

Oh, forgot to mention that I also changed the script to use r7-crystax-5.beta2, which fixes the HTTP-based profiler (r7-crystax-4 overrides the standard socket functions and then doesn't actually implement select() so everything breaks confusingly). If you don't care about the profiler then changing it back to the earlier NDK version should work.

Link to comment
Share on other sites

The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you

Link to comment
Share on other sites

I built public.zip, updated the source code and rebuilt it - tried everything you said, but still couldn't get it to work. Logcat doesn't seem to give much useful info other than that it crashed. I've attached the logs but I'm not sure if it will be of much use. I'm running it on a Samsung Galaxy R which has processing power comparable to the SGS2 (With a different processor family, though).

@Brian - Good to know that you remember! Yeah, I regularly follow development and always have my source code up to date :) Really wish I could still contribute, but don't find time to do it. Work it hectic as it is. The Android port will probably help provide the motivation I need to find time to start contributing again (I'm really into Android these days).

log.txt

Link to comment
Share on other sites

That says:

I/DEBUG   (21117): Build fingerprint: 'samsung/GT-I9103/GT-I9103:2.3.5/GINGERBREAD/XWKI5:user/release-keys'
I/DEBUG (21117): pid: 22328, tid: 22337 >>> org.libsdl.app <<<
I/DEBUG (21117): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 823ed560
I/DEBUG (21117): r0 00082c20 r1 00000000 r2 00000001 r3 82c20e28
I/DEBUG (21117): r4 82c002ac r5 0000010f r6 00000004 r7 480e89c8
I/DEBUG (21117): r8 480e8b40 r9 40086fb8 10 40086fa4 fp 802a5374
I/DEBUG (21117): ip 82c00390 sp 480e89c8 lr 823ed4e7 pc 823ed560 cpsr 20000030
[...]
I/DEBUG (21117): #00 pc 003ed560 /data/local/libpyrogenesis_dbg.so
I/DEBUG (21117): #01 lr 823ed4e7 /data/local/libpyrogenesis_dbg.so
I/DEBUG (21117):
I/DEBUG (21117): code around pc:
I/DEBUG (21117): 823ed540 00001608 b085b590 4c2aaf00 6078447c
I/DEBUG (21117): 823ed550 58e34b29 60fb681b eeff687b edc30b00
I/DEBUG (21117): 823ed560 687b0b10 0200f04f 687b60da 0200f04f
I/DEBUG (21117): 823ed570 687b611a 0200f04f 687b615a 4b1f681a
I/DEBUG (21117): 823ed580 681b447b 46194610 e18ef20d 46184603
[...]
I/DEBUG (21117): stack:
[...]
I/DEBUG (21117): #00 480e89c8 00000004
[...]
I/DEBUG (21117): 480e89e4 823ed4e7 /data/local/libpyrogenesis_dbg.so
[...]
I/DEBUG (21117): 480e8a0c 823ef25f /data/local/libpyrogenesis_dbg.so

so to (hopefully) see where it's failing, run


~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ed560
~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ed4e7
~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ef25f

(pc is current function, lr is caller, and any line after #00 in the stack that's labelled with the .so name is probably part of the call stack. You need to mask off the leading "82" in the addresses because the code was relocated at runtime, I think.)

Since this is an ILL_ILLOPC (illegal opcode), I think it's most likely due to differences in CPU. Galaxy R apparently uses Tegra 2, which is Cortex-A9 (like Galaxy S2) but without NEON (unlike Galaxy S2), and the game is compiled to assume NEON support. Try editing build/premake/premake4.lua and remove the "-mfpu=neon", and also edit build/android/setup-libs.sh to remove the "-mfpu=neon", then clean and rebuild everything, and it might be happier.

(In particular, the instruction just before the pc (i.e. the one whose execution triggered the exception, if I understand this correctly) is "edc30b00", which is "vstr d16, [r3, #64]" and therefore requires NEON support, so that seems a plausible explanation. Edit: Oops, I keep getting confused by endianness. The vstr is actually "edc3 0b10", and the problem is more likely the earlier "eeff 0b00 fconstd d16, #240" starting at 823ed55a, though I don't understand quite how the reported pc value (6 bytes later) relates to that.)

Link to comment
Share on other sites

Thanks a ton for your help Philip, but it still isn't working :(

Now I'm getting a different error:



I/DEBUG (26951): Build fingerprint: 'samsung/GT-I9103/GT-I9103:2.3.5/GINGERBREAD/XWKI5:user/release-keys'
I/DEBUG (26951): pid: 27139, tid: 27148 >>> org.libsdl.app <<<
I/DEBUG (26951): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG (26951): r0 00000027 r1 deadbaad r2 80000000 r3 00000000
I/DEBUG (26951): r4 00000001 r5 00000000 r6 00000001 r7 afd42718
I/DEBUG (26951): r8 48109b40 r9 442b9fb8 10 442b9fa4 fp 802a5374
I/DEBUG (26951): ip afd466c8 sp 48108910 lr afd19711 pc afd161e0 cpsr 60000030
I/DEBUG (26951): d0 3f80000000000000 d1 40dfae1400000000
I/DEBUG (26951): d2 be5acaf22c836220 d3 4014000000000000
I/DEBUG (26951): d4 3fe00000001ec5bd d5 4187e02ec0000000
I/DEBUG (26951): d6 4000668b9fdbd2fa d7 4000668b9fdbd2fa
I/DEBUG (26951): d8 0000000000000000 d9 0000000000000000
I/DEBUG (26951): d10 0000000000000000 d11 0000000000000000
I/DEBUG (26951): d12 0000000000000000 d13 0000000000000000
I/DEBUG (26951): d14 0000000000000000 d15 0000000000000000
I/DEBUG (26951): scr 20000010
I/DEBUG (26951):
I/DEBUG (26951): #00 pc 000161e0 /system/lib/libc.so
I/DEBUG (26951): #01 lr afd19711 /system/lib/libc.so
I/DEBUG (26951):
I/DEBUG (26951): code around pc:
I/DEBUG (26951): afd161c0 2c006824 e028d1fb b13368db c064f8df
I/DEBUG (26951): afd161d0 44fc2401 4000f8cc 49124798 25002027
I/DEBUG (26951): afd161e0 f7f57008 2106ea16 eb8af7f6 460aa901
I/DEBUG (26951): afd161f0 f04f2006 95015380 95029303 eef0f7f5
I/DEBUG (26951): afd16200 462aa905 f7f52002 f7f5eefc 2106ea02
I/DEBUG (26951):
I/DEBUG (26951): code around lr:
I/DEBUG (26951): afd196f0 4a0e4b0d e92d447b 589c41f0 26004680
I/DEBUG (26951): afd19700 686768a5 f9b5e006 b113300c 47c04628
I/DEBUG (26951): afd19710 35544306 37fff117 6824d5f5 d1ef2c00
I/DEBUG (26951): afd19720 e8bd4630 bf0081f0 00027e6c ffffff88
I/DEBUG (26951): afd19730 b086b570 f602fb01 9004460c a804a901
I/DEBUG (26951):
I/DEBUG (26951): stack:
I/DEBUG (26951): 481088d0 afd426c4
I/DEBUG (26951): 481088d4 000a5d40
I/DEBUG (26951): 481088d8 0000002b
I/DEBUG (26951): 481088dc afd187d9 /system/lib/libc.so
I/DEBUG (26951): 481088e0 afd42664
I/DEBUG (26951): 481088e4 afd46838
I/DEBUG (26951): 481088e8 00000000
I/DEBUG (26951): 481088ec afd19711 /system/lib/libc.so
I/DEBUG (26951): 481088f0 00000001
I/DEBUG (26951): 481088f4 48108924
I/DEBUG (26951): 481088f8 00000001
I/DEBUG (26951): 481088fc afd42718
I/DEBUG (26951): 48108900 48109b40
I/DEBUG (26951): 48108904 afd18a33 /system/lib/libc.so
I/DEBUG (26951): 48108908 df002777
I/DEBUG (26951): 4810890c e3a070ad
I/DEBUG (26951): #00 48108910 00000001
I/DEBUG (26951): 48108914 afd18825 /system/lib/libc.so
I/DEBUG (26951): 48108918 0000000a
I/DEBUG (26951): 4810891c afd1cd37 /system/lib/libc.so
I/DEBUG (26951): 48108920 afd42670
I/DEBUG (26951): 48108924 fffffbdf
I/DEBUG (26951): 48108928 442b9fb8
I/DEBUG (26951): 4810892c afd42670
I/DEBUG (26951): 48108930 82a6cdc4 /data/local/libpyrogenesis_dbg.so
I/DEBUG (26951): 48108934 813a58c8 /data/data/org.libsdl.app/lib/libSDL2.so
I/DEBUG (26951): 48108938 00493530
I/DEBUG (26951): 4810893c 00000000
I/DEBUG (26951): 48108940 00493588
I/DEBUG (26951): 48108944 00493530
I/DEBUG (26951): 48108948 82c002ac
I/DEBUG (26951): 4810894c 00493588
I/DEBUG (26951): 48108950 48108980
I/DEBUG (26951): 48108954 813a4dc8 /data/data/org.libsdl.app/lib/libSDL2.so

Link to comment
Share on other sites

It might be useful to know the lines logged by the engine before it crashes - it's possible that it's reporting an error and then abort()ing. Otherwise, addr2line might help - give it libpyrogenesis_dbg.so and address "00a6cdc4" (from the stack), and also get a copy of your /system/lib/libc.so (I think "adb pull" should be able to do that) and run addr2line with libc.so and maybe addresses "000161e0" and "00019711" and "00018a33" and "00018825" and "0001cd37".

Link to comment
Share on other sites

It might be useful to know the lines logged by the engine before it crashes - it's possible that it's reporting an error and then abort()ing. Otherwise, addr2line might help - give it libpyrogenesis_dbg.so and address "00a6cdc4" (from the stack), and also get a copy of your /system/lib/libc.so (I think "adb pull" should be able to do that) and run addr2line with libc.so and maybe addresses "000161e0" and "00019711" and "00018a33" and "00018825" and "0001cd37".

I haven't had a chance to try it out. I'll let you know when I get time to check it out.

Thanks!

Link to comment
Share on other sites

  • 2 weeks later...

Hi ive had my eye on this project for a while, but never jumped into it because the system requirements. But seeing what has progessed on the android has caught my attention.

I would like to try to give the work on the andriod version a try on the pandora (a portable linux based handheld). It has very similar hardware to some mobile phones.

My version has 256 mb ram (current builds will have 512 mb ram). It supports GLES2.

Pandora would certainly be ideal mobile device given that it has superior controls to anything out there. Meaning touchscreen, qwerty keyboard, game buttons, analog nubs.

What I would like to know is at what point in the svn i should target, i.e. is the latest stuff in the trunk or on some branch.

Reviewing this thread i saw talk about both SDL 1.2 and SDL 1.3, which is needed? Pandora can support either, although I would need to see if the latest SDL 1.3 state is in.

Are there any special things I should do for data? I saw some talk about precalced models and stuff.

Link to comment
Share on other sites

There are no branches, so you should use the latest SVN trunk code. SDL 1.3 got renamed to 2.0, and 1.2 doesn't support touchscreens, so you should use 2.0. For data, you should do the archivebuild thing from #155. This whole Android support is pretty rough so it probably won't work trivially, but hopefully it'll be possible to get something running :)

Link to comment
Share on other sites

There are no branches, so you should use the latest SVN trunk code. SDL 1.3 got renamed to 2.0, and 1.2 doesn't support touchscreens, so you should use 2.0. For data, you should do the archivebuild thing from #155. This whole Android support is pretty rough so it probably won't work trivially, but hopefully it'll be possible to get something running :)

Trunk it is then ;-)

Pandora's touchsreen is accessed through tslib (X input might be inbetween) which SDL 1.2 recognizes as absolute mouse input. Our SDL 2 port( 1.3 at the time) is missing control support last i tried. But I can start with either for video at least. Are both SDL versions supported?

I will be sure to let you know how it goes once I have some time to start working on it. Thanks for the pointers.

Edit: One other thing i wanted to mention, i saw some comments about needed to convert OpenAL, are you aware of the OpenAL-Soft project?

http://kcat.strangesoft.net/openal.html

This should be able to support any openAL funationality 0 ad uses.

Edited by Pickle
Link to comment
Share on other sites

The game should build fine with 1.2 or recent 1.3/2.0 (we use 1.2 on standard desktop Linux).

We run with OpenAL-Soft on Windows, so it does support what we need, but I don't think anyone has seriously examined audio support for Android yet, so I don't know if that'd be a good solution or not. Probably worth looking into.

Link to comment
Share on other sites

  • 3 weeks later...

Hey folks,

First post here, and I have no real coding experience (some Python, Ruby, Bash for sysadmin work), but the prospect of an Android port appeals to me greatly. Once I'm home with a little free time, I'll try to build it on my Asus Transformer Prime and get back to you. I figured, if nothing else, I could offer services and a modern Android device for development/alpha testing and documentation! And I'll probably learn a lot along the way.

I have more to read about the research you guys did into gesture controls (I haven't completely read the whole thread yet), but have a few ideas for intuitive navigation of the interface, and would also be interested in seeing keyboard/mouse controls available for those of us with Transformers Tablets In Disguise ;)

As a suggestion on how to make money with the release, you don't need to close the source, sell based on branding, or any other such thing. Try just making the first fully functional .apk of the game available through a Humble Bundle release. :) Humble Bundle has already done 2 successful Android-specific bundles, and something as impressive as a fully completed 0ad port to Android would be a sure draw. Release it later either by your own means as a pay-what-you-want, or free on the Android market with a donation version available. We open source folks are generous! Test us!

Link to comment
Share on other sites

  • 4 weeks later...

Building for Android will only ever be possible on Linux. (I updated the instructions here recently to use the various build scripts that I added some time ago, but it's still far from step-by-step instructions and is only suitable for people who are comfortable with debugging the build process and code themselves.)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...