Hello,

is there any update on the Android port also in terms of making it official and available for Android 2.0/2.1 or some of it's technical background in terms of features like filters and stuff? There hasn't been an update on gus's page for a while.

I'm using the 1.5 app on my i5700 Spica fine so far but I want to update to the recently released 2.1 Android in the near future and of course I'd love to be able to continue using ScummVM with all of my favourite games.

Best regards and thx to gus for his work on the port so far and everyone else on the ScummVM Team!

Delu

   

No news from the ScummVM team on this, it's all up to gus.

   

Ok, so I've put together a whole new Android NDK toolchain based on the Openembedded build system - currently only published here:
http://github.com/anguslees/openembedded-android

Using this toolchain, ./configure works and the build hacks all go away which removes the big blocker to merging. So I just have to rebase my patches on ScummVM trunk (instead of the 1.0 branch) and we should be good to go.


In another development branch, I have rewritten all the graphics to use OpenGLES rather than unpublished Android internal 2D graphics libraries that keep changing ABI between Android releases. I had this running on Android 2.0+ (and hopefully cyanogenmod again) just 2 days ago but it still has a few glitches (mouse cursor keycolor isn't working, etc). I also went for "portable" rather than "fast" OpenGLES choices, so it could be made much faster by using some newer GLES extensions.

More worryingly, there seems to be a change in Android 2.0 that breaks resolving symbols between dlopened libraries - necessary for the ScummVM plugins to work on Android. I haven't investigated this at all yet, and the fix may be as simple as some different compiler options.


So: lots of progress, but none of it is ready for a new release candidate just yet.

   

Heya gus,

although I'm not familiar with the actual coding or any at all I can just guess but it sure sounds exciting, like much effort and indeed lots of progress

Thx for the update and maybe someone else could help out with some of the stuff you mentioned above.

Best Regards
Delu

   

Can you pretty please publish the binary?

And, may I ask for a hint to some basic tutorial for building on openembedded?

Thank you!

   

quote:

---

Originally posted by singalen
Can you pretty please publish the binary?

---

quote:

---

Originally posted by singalen
And, may I ask for a hint to some basic tutorial for building on openembedded?

---

   

quote:

---

Originally posted by gus
The one that doesn't work yet?

I stashed a copy of my latest compile output as "scummvm-2.0alpha.apk" on here:

---

quote:

---

Originally posted by gus
I just put together this: http://wiki.github.com/anguslees/openembedded-android/
Let me know if any of that needs further explanation.

---

   

So how is it going? Also I've read the new scummvm release adds 16 bit support, wasn't that somehow already in your port?

   

quote:

---

Originally posted by Delu
So how is it going? Also I've read the new scummvm release adds 16 bit support, wasn't that somehow already in your port?

---

   

I still don't know enough to compile scummvm with openembedded. Looks like I need some bitbake conf files. Will study more.

I did some dumb mechanical porting of the patch to trunk. Here it is:
http://victorsergienko.com/files/scummvm/scummvm-android-trunk.patch.bz2
Though I have problems:
1. Some pieces of Android confguration seem to be already in.
2. I can't test building it for Android yet, and even for Linux it fails with an error: "/home/user/src/android/rel1.5/build/core/version_defaults.mk: No such file or directory". Will look into it later.

gus, some sort of further build instruction could help your followers For instance, ANDROID_SDK variable in ports.mk needs some mentioning.

Thank you

   

And it still would be really, really nice to get this port official. Right now, it seems to be a matter of chasing tails. Gus works hard on updating the port, once that is done, we (well, he can work on improving it, but !wham!, before it is done something new happens and Gus has to fix that, before he can return to clean up the new mess, etc., rince and repeat... Sad... Anyway, still hoping to see this become official. We could probably even provide daily builds via our buildbot etc.

All in all, I guess some extra man power would be good for the port .

   

quote:

---

Originally posted by fingolfin
And it still would be really, really nice to get this port official.

---

   

gus, if overriding the compiler and specifying special flags for using it is the only problem, we can certainly accommodate that in the current system without the need of a totally new tool chain, hopefully even without too much work.

Several ports have this requirement, in fact, at least for cross compiling. On our buildbot, for example, we typically invoke ScummVM's configure with something like this:

CXX=arm-eabi-gcc \
CXXFLAGS="-isystem /opt/MyCoolSDK/include -fancy-special-compiler-option \
LDFLAGS="-L/opt/MyCoolSDK/lib -fancy-linker-flag" \
./configure --enable-all-engines

This is not pretty, but works, and if this allows us to get the source quicker to SVN, I'd recommend using it (this invocation could even be put into a simple shell script in backends/platforms/android/). A better solution via support code in the configure script is of course nicer on the long run; but this approach sure beats having the whole port source in a separate tree, I think .

Once again, I'll be happy to try and assist you with this. I don't have an Android phone, nor do I currently have the Android SDK/NDK/whatever setup on my machine (can I do that on OS X?), but at least I know ScummVM pretty well, and working on our Buildbot have some experience with cross compiler setups. So I am quite hopefully we can get that done.

   

As for OpenGL ES: We are participating in Google's Summer of Code 2010, and some of the students have proposals revolving around writing OpenGL (ES and plain) code that can be reused between backends. This would, in theory at least, be then usable for the SDL, iPhone, Android, etc. ports.

   

Yep, indeed...the SDK is available for Mac OS X

http://developer.android.com/sdk/index.html

http://developer.android.com/guide/developing/tools/emulator.html