Topic: Android build

I'm working on an Android build of Maratis. So far I have been able to at least compile the essential parts for a player with the NDK:

-rw-r--r-- 1 anders anders 9,3M 11 feb 21.05 libbullet.a
-rw-r--r-- 1 anders anders 1,7M 12 feb 11.01 libfreetype.a
-rw-r--r-- 1 anders anders 579K 11 feb 21.05 liblua.a
-rw-r--r-- 1 anders anders 2,1M 11 feb 21.06 libMaratisCommon.a
-rw-r--r-- 1 anders anders 222K 11 feb 21.06 libMaratisOpenGLES.a
-rw-r--r-- 1 anders anders 3,8K 11 feb 21.06 libMaratisWavSound.a
-rwxr-xr-x 1 anders anders 270K 11 feb 21.06 libMCore.so
-rwxr-xr-x 1 anders anders 863K 11 feb 21.06 libMEngine.so
-rw-r--r-- 1 anders anders  70K 11 feb 21.05 libnpk.a
-rw-r--r-- 1 anders anders 270K 11 feb 21.05 libtinyxml.a

Edit: Forgot we needed to provide freetype on Android.

Last edited by Dahnielson (2014-02-12 10:05:20)

  • anael
  • Administrator
  • Offline

Re: Android build

Nice man !

What might be hard to use is OpenAL for the sound, I don't think it's supported natively on Android.
Maybe a third party lib like "OpenAL Soft" will be enough, or it will need a OpenSL sound context to replace the OpenAL one.

Re: Android build

anael wrote:

Nice man !

What might be hard to use is OpenAL for the sound, I don't think it's supported natively on Android.
Maybe a third party lib like "OpenAL Soft" will be enough, or it will need a OpenSL sound context to replace the OpenAL one.

Yes, I have been looking into the dependencies. Haven't written any sound context for the Android build yet. But I was thinking of adding OpenAL Soft as a dependency instead if I can get it integrated into the build system (it already uses CMake). It would benefit all the other platforms as well, replacing the aging proprietary binary implementation with a modern open source implementation that offers multiple of backends.

Last edited by Dahnielson (2014-02-17 22:39:41)

Re: Android build

Thats very nice having an android support.

  • VeganDev
  • Vegan, Humanitarian Game Developer
  • Offline

Re: Android build

I thought the NDK wasn't a very good option to use according to android ?
I know I read that somewhere.

From androids page :

" Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. "

Im all for getting a android port going, but I can't help but wonder is that relevant here at all is this just a option to avoid rewriting in java? ARe there converters ?

thx
vd

Last edited by VeganDev (2014-02-27 23:52:46)

  • anael
  • Administrator
  • Offline

Re: Android build

VeganDev : It's a portability reason, and it's a good reason for a lot of projects, but not when you code base is already c++.
The difficulty with c++ on Android is that you may need to compile multiple binary depending on the hardware.

  • anael
  • Administrator
  • Offline

Re: Android build

Dahnielson : I saw in your github that you made a lot of work on native image loaders and sound loaders, that's awesome smile
Is OpenAL Soft working as expected ?

Re: Android build

anael wrote:

Dahnielson : I saw in your github that you made a lot of work on native image loaders and sound loaders, that's awesome smile
Is OpenAL Soft working as expected ?

I haven't had any time to work on Maratis this week and I'm a little bit ashamed to say that I haven't properly tested it. I just integrated, built, ran, saw that it at least didn't segfault and commited it to Github. wink So I can't really say anything about OpenAL Soft yet. The same goes for the Ogg Vorbis loader I implemented just so I could test OpenAL, as I had problem loading sounds using SndFile.

My plan is to also implement a native image loader for DDS files, so S3TC compressed textures can be directly loaded into texture memory, as off-line compression (using e.g. Nvidia Texture Tools) is way better than letting the graphics chip set do it on-line.

I've also been poking around with the idea of implementing a new type of data loader to stream audio and video. At least doing the first one as loading game music completely into memory is a bit waste of memory.

Last edited by Dahnielson (2014-03-01 13:10:13)