State of the Android port (1.5-2.1) |
Author
|
Thread |
 |
|
Delu
Joined: 27 Mar 2010
Posts: 12
|
State of the Android port (1.5-2.1)
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
|
Sat Mar 27, 2010 9:57 am |
|
|
fingolfin
Retired
Joined: 21 Sep 2005
Posts: 1466
|
No news from the ScummVM team on this, it's all up to gus.
|
Sat Mar 27, 2010 7:05 pm |
|
|
gus
ScummVM Porter
Joined: 13 Feb 2009
Posts: 77
|
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.
|
Sat Mar 27, 2010 10:54 pm |
|
|
Delu
Joined: 27 Mar 2010
Posts: 12
|
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
|
Sun Mar 28, 2010 10:50 am |
|
|
singalen

Joined: 01 Mar 2006
Posts: 13
|
Can you pretty please publish the binary?
And, may I ask for a hint to some basic tutorial for building on openembedded?
Thank you!
|
Mon Mar 29, 2010 4:09 pm |
|
|
gus
ScummVM Porter
Joined: 13 Feb 2009
Posts: 77
|
quote: Originally posted by singalen Can you pretty please publish the binary?
The one that doesn't work yet?
I stashed a copy of my latest compile output as "scummvm-2.0alpha.apk" on here: http://sites.google.com/site/scummvmandroid/dev/
quote: Originally posted by singalen And, may I ask for a hint to some basic tutorial for building on openembedded?
I just put together this: http://wiki.github.com/anguslees/openembedded-android/
Let me know if any of that needs further explanation.
|
Mon Mar 29, 2010 11:35 pm |
|
|
singalen

Joined: 01 Mar 2006
Posts: 13
|
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:
Ah, thank you.
I hoped it had worked at least some way - if the transition didn't require complete switch to another API.
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.
That's pretty clear, now building toolchain. Just needed a kick to start.
At least, I can do some dumb work like porting the patch. Is it necessary, or you plan to use OpenGLES only?
May I ask you another dumb question - what's the point of not using Android NDK? Are there any problems using its arm-eabi-g++ and everything to build ScummVm?
I seem to randomly google to couple of known bugs in Android with dlopen(). Though, I really don't know is it what you encountered.
Discussion one, discussion two, bug 599, bug 2042
If someone tries this too, FYI:
* On Ubuntu 9.10, I had to install bitbake-1.8.18, as 1.8.12 crashed with errors like "NameError: global name 'os' is not defined". Looks this is a known bitbake bug, I registered an update request for Ubuntu.
After installing it by hand, I had to set PYTHONPATH to its lib dir.
* I also had to "dpkg-reconfigure dash" and answer "No".
* openembedded's sanity check requests to install several utilities. I needed: apt-get install help2man diffstat texi2html texinfo cvs
Ah, configure --help doesn't mention Android as --backend and --host.
|
Thu Apr 01, 2010 10:27 pm |
|
|
Delu
Joined: 27 Mar 2010
Posts: 12
|
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?
|
Wed Apr 07, 2010 4:59 pm |
|
|
|
|
fingolfin
Retired
Joined: 21 Sep 2005
Posts: 1466
|
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 .
|
Sat Apr 10, 2010 11:46 pm |
|
|
gus
ScummVM Porter
Joined: 13 Feb 2009
Posts: 77
|
quote: Originally posted by fingolfin And it still would be really, really nice to get this port official.
Totally.
singalen: the custom NDK is to try to make merging with ScummVM easier/possible. The current patch (in ScummVM bug tracker) includes some ugly hacks to ports.mk, which make it unacceptable for merging (like overriding the compiler used!).
The Google NDK's arm-eabi-gcc can't compile anything without a required set of command line flags, which makes it impossible to use with the ScummVM configure script. In order to build with arm-eabi-gcc, you need to hack something up to get configure to run, and then undo your hacks to actually build something correctly (hence the ports.mk overrides in the current patch). With a proper arm-android-eabi-gcc toolchain (like my openembedded one, or any of the ones that other people have put together), this goes away and all becomes sweetness and light.
I got suckered into trying to get something to work on Android 2.0 again, which I said I wouldn't do. Instead I'll just port the current crap to ScummVM trunk and work on getting it merged. Then *we* can work on making it cleaner.
Fwiw, I've concluded that OpenGLES sucks for ScummVM's needs (in particular, afaics it's impossible to incrementally update a texture in a way that supports pitch/stride). I'm going to chuck the last few months of work and go back to the simple Android 2D stuff.
|
Mon Apr 12, 2010 12:21 am |
|
|
fingolfin
Retired
Joined: 21 Sep 2005
Posts: 1466
|
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.
|
Mon Apr 12, 2010 12:01 pm |
|
|
fingolfin
Retired
Joined: 21 Sep 2005
Posts: 1466
|
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.
|
Mon Apr 12, 2010 12:02 pm |
|
|
|
|
Forum Rules:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|
Powered by phpBB © 2001, 2006 phpBB Group
Forum design by ScummVM team, icons by raina
|
|