State of the Android port (1.5-2.1)

[singalen]

I attempted to compile with Google's NDK, with minimal intrusion into ports.mk, only presetting environment variables.

I cleaned up some duplication in the patch among ports.mk and ./configure. I believe most part of ports.mk changes is unnecessary.

I'm afraid it won't do, as the port would need a whole lot of unpublished stuff, like Skia, and it won't be published and supported anyway...

So, getting back to OpenEmbedded with compiled skia and everything.

[fingolfin]

At least in the last revision of the android patch that I reviewed (see https://sourceforge.net/tracker/?func=d ... tid=418822 ) none of the ports.mk changes were necessary. I haven't seen a patch since then, though, thus I can't be 100% sure whether this is still the case, but it seems likely.

[gus]

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.

Cool. I have working code for a reasonably portable Android GLES version, if that helps anyone. I was rewriting it to use pbuffers, but didn't finish getting the bugs out of that version. The iPhone backend renders everything to a single texture and uses GLES to draw the texture - my code keeps the game, overlay and cursor as 3 separate textures and uses GL to do the compositing too.

The main difficulties I hit were:
- ScummVM's use of 8bit paletted images (which GLES supports only poorly)
- non-contiguous rows of pixel data (ie: pitch) (which GLES doesn't support, but GL does).
- grabOverlay and lockScreen want read access to images, which is potentially expensive with GL(ES)

It would also be easier to optimise things if copyRectToOverlay had an "ok, we're done drawing a batch of regions - now update the screen" signal, like the normal game screen does via updateScreen.

[gus]

At least in the last revision of the android patch that I reviewed (see https://sourceforge.net/tracker/?func=d ... tid=418822 ) none of the ports.mk changes were necessary. I haven't seen a patch since then, though, thus I can't be 100% sure whether this is still the case, but it seems likely.

They were necessary in the 1.0 branch because of the order that makefiles were included. They aren't necessary post 1.0, when a lot of the ports.mk stuff was split out.

I have the "nice" version of the build changes right here and working. I just need to port it from 1.0 to trunk - which is a bit awkward due to the revision control tools I'm using at the moment (it doesn't understand rebasing between svn branches so I need to dump it all out as a plain diff and then wiggle everything back onto the new branch).

[ch4rlii]

Thank you Angus for the Android port of ScummVM!
I got an Android Netbook and wondered if it would be very hard to use the mouse move commands of the real mouse to move the cursor accordingly.
I think there are more Android Nebooks coming, (from 50EUR on eBay) with and without touchscreen and for those with a mouse, the current implementation is an unnecessary complication.

Thank you in advance!
Regards,
Charly

EDIT: FYI:
http://global.ebay.com/search?Query=netbook+android

[Darksol]

Any progress so far?
I'm deciding flashing back to 1.5 Android or not just for ScummVM

Keep up the good work. Please please please

[gus]

I got an Android Netbook and wondered if it would be very hard to use the mouse move commands of the real mouse to move the cursor accordingly.

Interesting! It should be easy to add - I just have to know what to add ;)

I couldn't find the answer from 30s of websearching - how do the mouse events turn up in the Android API?
Is there a system mouse cursor now - and can an app change what the cursor looks like? (I had to implement my own mouse cursor for other Android devices)

[ch4rlii]

Hi,
I don't know anything about the API, but: Yes I have a system mouse cursor and an app can change the look of the cursor. Opera Mini and ScummVM, both have a second cursor, which position is only updated after a left-click.
Except ScumVM, I don't think I have an app where the mouse-over event is essential...
The netbook is running Android v1.5.2, but there are other netbooks with v2

[Warzone]

Hmmm are you going to be waiting for 2.2 froyo to hit or gonna still target 2.1?

[Stremon]

Any news about the android 2.1 release ?
Can't wait to play my old games on my HTC Desire

[Rhendash]

Any news about the android 2.1 release ?
Can't wait to play my old games on my HTC Desire

+1 and UP ^^

I know a lot of people interested in Scummvm android.
And the community "android" keeps growing.

[Warzone]

http://www.youtube.com/watch?v=yAZYSVr2Bhc

[flitzjoy]

I´m really disappointed that scumm isnt ready yet to run on Android. Being a huge Lucas Arts Adventures fan and a previously owner of Symbian and WinMo phones, I´m used to have nice games in my pocket.

Please devs take Android as a more relevant priority, its the mobile platform that grows more quickly now.

[Anotherguest]

Biggest problem with Android is that is mainly a java platform and not a C/C++ platform. Using those C/C++ apis takes alot of time and skill and that is what you are waiting for right now.

[voodoo_pirate]

So forgive my ignorance with code and development and all that, but does this mean that every time the android OS is updated, whatever version of VM that works will be outdated?

So basically, if there were a version that worked with 2.1, would it be useless when 2.2 hits?

If so, that seems like it might be a huge problem considering how frequently OS updates seem to happen with android.