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).
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.
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
). 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.
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.
