UFO:AI Android port

[pelya]

A port of UFO:AI to Android mobile platform.
Google Play page
Android package file

You will need 1Gb RAM on your device (you'll get a warning if you have less), also it will download 1Gb data on the first launch.

[Mattn]

Quite cool. I have a galaxy s 9000. I'm very interested in this port. Unfortunately i have little time right now. But i will have a look tomorrow.

[bayo]

hehehe very nice. I download myself your framework port to android few weeks ago to work around UFOAI and Android... i dont yet check it, but sure u do a better job than me.

Thanks for your job. I will take a look too. Soon i will have some android phones and tablets to test what we can do with it. I think we can aim to provide a skirmish mode quite well. But it will need work.

BTW i dont think aiming the full game is a very good idea. That's IMO another subprojet, cause it really need too much work.

[geever]

BTW i dont think aiming the full game is a very good idea. That's IMO another subprojet, cause it really need too much work.

I've been thinking about if we could have a minihud or 2d hud version for older PCs or even phones/tablets that doesn't require much resources but the game would be still fun to play.

-geever

[bayo]

hope to have time to work on http://mattn.ninex.info/files/android/test-dyn.svg
maybe we also need to have special release pipeline to reduce texture size, or tweek thing like that
and use "simple" maps, with only one floor (or only few)

but what do you mean by  2d hud?

[geever]

but what do you mean by  2d hud?

Well, not only hud but renderer/battlescape/whatever. Maybe topdown or fixed isometric view. The goal is to be fast&light.
The game is slow and waste resources now imho.

-geever

[Mattn]

it would be really cool if you could attach the ufoconsole.log of the android startup.

[H-Hour]

Re: maps. I'm happy to create a few simple one-level maps that use very basic brushes.

Alternatively, what about pre-rendering all the maps into isometric images that are spliced together? I guess there would still be the problem of calculating visibility.

[geever]

Alternatively, what about pre-rendering all the maps into isometric images that are spliced together? I guess there would still be the problem of calculating visibility.

Radar images? We have support for tactical radar images but we lack most of them. They could be used as a top-down 2D map with some additional info about visibility.

-geever

[H-Hour]

Radar images? We have support for tactical radar images but we lack most of them. They could be used as a top-down 2D map with some additional info about visibility.

Yeah, although I was thinking more like at a 45 degree angle, like the old-school X-Com stuff. Top-down will only work if we want to get rid of all vertical play and have all the soldiers/aliens/civs walk only on one z-level.

I'm not opposed to that if it's important to make it low-impact for the Android, just saying.

[bayo]

rasterising a map, and allow to play it is imo a very big computation problem. No idea if it is possible.

BTW have you test to reduce texture sieze ? 1x1 32x32 pixels? can it help old card to work? A little script can do the job if it is need.

IMO your alien base looks quite simple and nice.

[pelya]

So, did anyone succeed running this? I still cannot push to the Ufoai Git also I've found more bugs in my code, need time to fix them though.

rasterising a map, and allow to play it is imo a very big computation problem. No idea if it is possible.

That seem not that complicated if we'll just use OpenGL - from the map editor render each map tile to an off-screen surface or even to the screen (I mean big tile, like dropship or UFO), then get the resulting image and Z-buffer values using glReadPixels(). Then for each individual small tile, where soldiers will stand, check Z-buffer value and determine if there are any pixels that will cover the soldier, and also save that "visibility" images.
Then repeat for each floor level.
Those big tiles can be combined on-the-fly into an isometric game level just like you're doing that in 3D (but you'll have to combine "visibility" images on the tile borders, not that complicated too).

When rendering the soldiers there are two ways:

1. Draw the background to the near Z-Buffer plane. Then for each soldier, sorted from top to bottom:
    Disable Z-Buffer check.
    Render soldier 3-D model onto the background, so it will make a depth "hole" in Z-Buffer.
    Enable Z-buffer check
    Draw the "visibility" image with some alpha-blend value to the near Z-Buffer plane, that will make soldier model half-transparent but other background pixels will not change, because it will be applied only to a "hole" in Z-Buffer.
    This will also fill the "hole" in the Z-buffer, so when you'll render next soldier which will be close to the previous one the "visibility" image will not be applied twice on the first soldier.

2. Draw the background to the far Z-Buffer plane. Then for each soldier, sorted from top to bottom:
    Render soldier 3-D model normally.
    Call glAlphaFunc() so only non-transparent pixels will modify Z-Buffer.
    Draw the "visibility" image right before soldier with some alpha-blend value, that will make soldier model half-transparent, but will not change background pixels 'cause they have the same value.
    If two soldiers will stand near each other the "visibility" image from the second one may be applied to the first one, and this will create drawing artifacts.

That sounds easy, but require lot of developer time and small details sorted out.

Edit: I've made another build, with slightly less memory usage - it uses just 170 Mb with loaded main menu.

[bayo]

There is some more thing to do for translucent and destructible surfaces (and maybe more?). But using zbuffer looks very interesting. But according to the fact that our top-down radar "feature" is waiting for a real autogen tool, i dont think wev got skill to do it, or no body take care about it.

[pelya]

So, we DO have destructible surfaces? 

[Kildor]

a bit of.