Author Topic: Android Port (Old)  (Read 53842 times)

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #30 on: September 21, 2011, 04:18:14 am »
You... you... you optimized the globe?? You tamed the beast?!?!? :o :o

Please, by all means, share with us your crazy voodoo magic because the globe has grown into this horrible monster that we have settled with "just works" and nobody dares to adventure down into its lair anymore, lest we make it worse.

Oh, I made it worse long before I made it better...  And still sometimes Europe falls into the sea until the end of the day...  And if you go into the basescape then back out to the geoscape your bases disappear for some reason.  Completely gone.

The biggest thing I did is created a new image that contained all the land and only drew to it when the shade changed or when you rotate the globe.  Then I modified your calculations for the shades of the sea and removed a LOT of creating Vectors and destroying them just to create them again... Then I stopped drawing things that are off the screen when you are zoomed in really far.

The garbage collector in Java takes a lot of time, so creating and destroying objects is horrible for Android gaming.  I'm sure I made many many more optimizations, but I'm not near my code right now.  I'll see what I can define and share as an improvement.  I'll try to take a movie of me playing around in the geoscape on my phone to see what you guys think.

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #31 on: September 21, 2011, 04:32:31 am »
you probably dont find any big improvement here. most demanding part of battlescape is bliting but this is already optimized.

From what I found it is horrible with respect to memory savings, which is very important on Android as I only have 16 megs to work with.  Each 320*200 surface takes up 256k.  The memory gets taken up very fast in bitmaps.

The battlescape uses a rectangular surface for every possible movement position on the map.  A standard game map would be 10000 possible positions.  Each surface set up for these is something like 30*40 pixels.  That alone is 48 megabytes.  I need to find a way of making that use less than 16.  I haven't started it yet so I don't know exactly how I plan on accomplishing it.  If anyone has any ideas I would be glad to hear them.

Volutar

  • Guest
Re: Android Port
« Reply #32 on: September 21, 2011, 05:15:48 am »
Standard XCOM battlescape map could have only 255 possible tiles 32x40 pixel sized. Plus unit and groundobjects. That's really a few. Caching those tiles with lighting applied (for night mission) may deal alot more memory consumption. The only way is not to cache all these things. When you have little memory size, this could be a perfomance booster.

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #33 on: September 21, 2011, 06:06:41 am »
Standard XCOM battlescape map could have only 255 possible tiles 32x40 pixel sized. Plus unit and groundobjects. That's really a few. Caching those tiles with lighting applied (for night mission) may deal alot more memory consumption. The only way is not to cache all these things. When you have little memory size, this could be a perfomance booster.

That is pretty much what I want going to try to do.  There have to be only a set number of permutations of damage/lighting/whatever else may happen to a tile.  So I was thinking of just having the 10,000 map tiles have pointers to what they currently contain based on the permutations for that map.  But that is so far from the current code it will take me plenty of time to figure out how to accomplish that.

Another option is to have the tiles chached and only create the surface when the tile is visible, instead of creating them when generating a map.  But that would cause a lot more object creation/destroying and give me glitchy UI because of the stupid garbage cleaner...  So many pro's and con's.

Thanks for ideas.  Very welcome.

Volutar

  • Guest
Re: Android Port
« Reply #34 on: September 21, 2011, 10:14:39 am »
Currently openxcom redraws whole battlescape view (not whole map) every single frame, even if nothing happening.

In original xcom full redraw happen only for map animations such as smoke/fire and alien entertainment.
Map scrolling done with direct scrolling + redraw only new fragments. While scrolling animating is turned off (to avoid glitches).
Unit walking, firing, explosions done with kind of dirty rectangles redraw (actually they used predefined short lists of tiles to redraw, this lists are for different directions of movement (small/large units) and explosion).
No caching used at all. All sprites decoded and directly drawn on mem surface. With double bufferring.

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: Android Port
« Reply #35 on: September 21, 2011, 12:29:16 pm »
Not sure which version you are using, but since 0.3 there is no caching of tiles at all anymore. All thanks to our great blitNshade function ;)

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #36 on: September 21, 2011, 05:27:08 pm »
I'm currently running the June 3rd revision.  I haven't been worrying about the updates you guys make until I get a working version, then I can break it again adding in everything that you have done.  I'm thinking about doing that now though seeing all the progress you all have made while I've been tinkering...

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2114
    • View Profile
Re: Android Port
« Reply #37 on: September 21, 2011, 09:09:56 pm »
Oh, I made it worse long before I made it better...  And still sometimes Europe falls into the sea until the end of the day...  And if you go into the basescape then back out to the geoscape your bases disappear for some reason.  Completely gone.
Oh don't worry, that's completely normal, everytime anyone touches the globe it just seems to get even weirder, you'd be amazed with the crazy stuff we've seen during development (and some of it is still there waiting for some brave soul to fix it). :P

The biggest thing I did is created a new image that contained all the land and only drew to it when the shade changed or when you rotate the globe.  Then I modified your calculations for the shades of the sea and removed a LOT of creating Vectors and destroying them just to create them again... Then I stopped drawing things that are off the screen when you are zoomed in really far.
That's odd, it should already work like that. Though given how many people have dug into it, I don't know what's what anymore. :P

Basically the globe is split in 4 surfaces: markers (bases etc.), detail (territory names etc.), land and ocean. Each surface is only redrawn as necessary (hopefully), but most of the time everything needs to be redrawn.

This is because originally we had no light shading, so we only needed to redraw the markers every game tick and everything else just when the globe was rotated, so it performed pretty fast. But then the sun shading was added and so everything needs to be redrawn every game tick, which slowed things down. The biggest performance hog is the shaded ocean (if you comment out the Globe::drawOcean function you'll see the difference), since nobody's come up with an efficient way of drawing it and we don't have access to the original X-Com code.

Of course this is all tolerable on modern PCs, but a real drain on lower-end platforms like mobiles (and my ancient PC CPU :P). There's also lots of other aspects surrounding the globe that could improve mobile performance, like all the complex math (turning the flat map into a 3Dish globe) is done with radians stored in doubles and run-time trigonometry, while the original X-Com used degrees in integers with pre-calculated trigonometry (better for platforms without dedicated FPUs). Dirty rectangles and other techniques could probably also help.

We're more focused on functionality than efficiency at this point, so anyone that can understand and focus on optimization is always welcome. :)

you probably dont find any big improvement here. most demanding part of battlescape is bliting but this is already optimized.

From what I found it is horrible with respect to memory savings, which is very important on Android as I only have 16 megs to work with.  Each 320*200 surface takes up 256k.  The memory gets taken up very fast in bitmaps.

The battlescape uses a rectangular surface for every possible movement position on the map.  A standard game map would be 10000 possible positions.  Each surface set up for these is something like 30*40 pixels.  That alone is 48 megabytes.  I need to find a way of making that use less than 16.  I haven't started it yet so I don't know exactly how I plan on accomplishing it.  If anyone has any ideas I would be glad to hear them.
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P

I'm currently running the June 3rd revision.  I haven't been worrying about the updates you guys make until I get a working version, then I can break it again adding in everything that you have done.  I'm thinking about doing that now though seeing all the progress you all have made while I've been tinkering...
Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)
« Last Edit: September 21, 2011, 10:05:08 pm by SupSuper »

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #38 on: September 21, 2011, 09:58:33 pm »
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P

Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)

Yeah, I changed it into more of a real-time loading system where if a surface is needed it is loaded real time and deleted once it is no longer being used.  That seemed to help me out a lot.

And I do believe a lot has changed, you people have way more free time than I somehow.  I wish I could accomplish as much.

Once I optimized the land drawing I did notice that the ocean took the longest.  I tried figuring out the calculations behind the shading but gave up quite quickly because I had other fish to fry.  But I will most likely look into it since it's what is slowing down my globe currently.  That and the cacheing of the land when you move the globe at all.  That takes up a lot of time as well.  I would like the caching of the land to take much less time.  It would make the UI much more fluid.

Offline Yankes

  • Commander
  • *****
  • Posts: 2078
    • View Profile
Re: Android Port
« Reply #39 on: September 22, 2011, 12:14:14 am »
you probably dont find any big improvement here. most demanding part of battlescape is bliting but this is already optimized.

From what I found it is horrible with respect to memory savings, which is very important on Android as I only have 16 megs to work with.  Each 320*200 surface takes up 256k.  The memory gets taken up very fast in bitmaps.

The battlescape uses a rectangular surface for every possible movement position on the map.  A standard game map would be 10000 possible positions.  Each surface set up for these is something like 30*40 pixels.  That alone is 48 megabytes.  I need to find a way of making that use less than 16.  I haven't started it yet so I don't know exactly how I plan on accomplishing it.  If anyone has any ideas I would be glad to hear them.
as Daiky said you should check out new version of Battlescape  (at least you should look at differences), its a lot faster than previous one. and probably use less memory.

The garbage collector in Java takes a lot of time, so creating and destroying objects is horrible for Android gaming.  I'm sure I made many many more optimizations, but I'm not near my code right now.  I'll see what I can define and share as an improvement.  I'll try to take a movie of me playing around in the geoscape on my phone to see what you guys think.
deleting/creating object in c++ is slow too, but because vast memory and speed of cpu we dont see it often. every optimization will work on both version :)

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2114
    • View Profile
Re: Android Port
« Reply #40 on: September 22, 2011, 03:16:20 am »
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P

Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)

Yeah, I changed it into more of a real-time loading system where if a surface is needed it is loaded real time and deleted once it is no longer being used.  That seemed to help me out a lot.

And I do believe a lot has changed, you people have way more free time than I somehow.  I wish I could accomplish as much.

Once I optimized the land drawing I did notice that the ocean took the longest.  I tried figuring out the calculations behind the shading but gave up quite quickly because I had other fish to fry.  But I will most likely look into it since it's what is slowing down my globe currently.  That and the cacheing of the land when you move the globe at all.  That takes up a lot of time as well.  I would like the caching of the land to take much less time.  It would make the UI much more fluid.

Well the land cache is a trade-off. It makes it faster when the globe is standing still, since no need to recalculate the land polygons when they don't move, but makes it slower to rotate because of the constant cache regeneration. Most of the time the globe isn't moved so I figured that was more important.

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #41 on: September 22, 2011, 03:25:40 am »
Well the land cache is a trade-off. It makes it faster when the globe is standing still, since no need to recalculate the land polygons when they don't move, but makes it slower to rotate because of the constant cache regeneration. Most of the time the globe isn't moved so I figured that was more important.

I agree.  It is much faster the way it is now when you are not rotating.  But I want them both to be fast danget!  I have the cake sitting next to me, I want to eat it.

And for the battlescape I will be putting in the most recent version soon before I start to mess with it.  It will just make my life easier to start with if there are already process improvements in place that I probably wouldn't have thought of in the first place.

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
Re: Android Port
« Reply #42 on: September 22, 2011, 05:58:21 am »
Holy cow...

Is there an easy way to go through code and merge in updates?  I've been at this for 2 hours and only done 8 files.  there are over 200 files that I need to go through.  At 15 minutes each this will take for bloody ever.

I am willing to hear any trick anyone may have.

Offline michal

  • Commander
  • *****
  • Posts: 632
    • View Profile
Re: Android Port
« Reply #43 on: September 22, 2011, 07:11:55 am »
Well i guess it is biggest downside of translating code to other language. Maybe it would be better for you to wait until 1.0 will be released and translate it once, but completely (and maybe in future, when new version will be released).

Volutar

  • Guest
Re: Android Port
« Reply #44 on: September 22, 2011, 07:27:07 am »
SupSuper, how do you cache globe graphics?
As rendered bunch of poly bitmaps? Or as transformed to screenspace visible poly coords? I really hope it's the second way :)