Messages

1

Builds & Ports / Re: Android Port

« on: September 23, 2011, 01:00:29 am »

The ocean, however, isn't. Technically it doesn't really exist, there are no pre-existing polygons or anything, the land is just placed on top of a blue circle. So to shade it like a sphere, which is a lot smoother than the land, a lot of complex expensive stuff goes on, I'm not really sure what since I didn't code it. But I presume the game basically has to generate polygons for the ocean, figure out their positions up to the circle edge, convert them, shade them, draw them, all this every game tick. It's constantly caching so it can't be cached or whatever either. It's basically a really ugly mess and nobody's figured out a fast way of doing it yet.

What if you created a fine grid of longitude strips and cached those every time you move the globe.  Then every game tick you would have to find out which longitudinal strips changed shade and redraw them, nothing else.  The problem I see with this method is finding where the edge of the globe is so you aren't drawing the back side of the earth.

This would definitely not help me with making globe motion smoother in my UI, but it might make the draw ever so slightly less.  I'll still work on making those ugly equations simpler or  at least less time consuming.  Is ther biggest problem with the globe the water shading?  (the "tame the beast" comment you made earlier)

2

Builds & Ports / Re: Android Port

« on: September 23, 2011, 12:55:56 am »

Putz you didnt get this :>
shadow edges on earth surface are circles (looking in 3d) and intersection of 2 spheres (again 3d objects) give this too. i dont need change radius of this spheres, only relative position.

Ahh, I got it.  You are talking actual 3d objects.  I was talking 3d appearance on 2d drawings.  I understand how it would work with multiple spheres intersecting and finding the intersecting surface (basically a circle around the sphere), but I have absolutely no idea how to code it...

3

Builds & Ports / Re: Android Port

« on: September 22, 2011, 09:54:17 pm »

i have probably great idea of speeding up globe drawing.

...

I was thinking of something like that, but the problem I see is there is an instance where the shade lines are straight up and down (curved a little, but the idea is there).  So the radius of the shading spheres would be infinite.    If that could work somehow it would make things very much faster.  I just didn't take the time to figure out how to calculate out the center and radius of the shade spheres as a function of centerlat, centerlon and time of day.  I know that the radius of the shade shperes would have to be a tangent function.

I also looked into fish-eye distortion.  Make a flat globe and just select the pixels out of that image to make it look like a sphere (less pixels from the top and bottom but all the pixels at the equator...)  That might work a bit faster, but It would take a little manipulation if you are viewing the north/south poles.

Is it the calculations for the shading polygons that takes the longest or actually shading and drawing them?

4

Builds & Ports / Re: Android Port

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

5

Builds & Ports / Re: Android Port

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

6

Builds & Ports / Re: Android Port

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

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.

7

Builds & Ports / Re: Android Port

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

8

Builds & Ports / Re: Android Port

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

9

Builds & Ports / Re: Android Port

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

10

Builds & Ports / Re: Android Port

« on: September 21, 2011, 04:18:14 am »

You... you... you optimized the globe?? You tamed the beast?!?!?

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.

11

Builds & Ports / Re: Android Port

« on: September 21, 2011, 01:18:52 am »

I read in another thread about no one being able to do optimizations.  I have made a LOT of optimizations because the hardware on a phone is much inferior that of a PC.  I'm sure a lot of what I fixed can be retranslated into C++ and help your system out a bit.  I've only focused on the globe so far since it was the real hog for resources...  I'm starting on the battlescape now.

I got the globe drawing down from 250 milliseconds to 7 milliseconds (on my phone).  Moving the globe works much faster as well.  Let me know if I can help you guys out at all instead of just me helping me.

12

Builds & Ports / Re: Android Port

« on: September 17, 2011, 05:01:51 am »

Hey.

I'm that guy...  And yes luck is needed.

Aso for the SDL and YAML stuff I just changed them to native android methods and XML.  (Honestly I haven't tested the XML just yet, but I'm sure I'm close even though it's my first time writing JAVA XML code.  I'm not sure why I'm doing a full code conversion, maybe it's in the hope that if I ever get an interview for a software job I can have something to show.

So far I've got the geoscape and all it's parts working.  I can down UFO's and go to them but once you get into the battlescape the colors get slightly interesting.  That is what I am working on resolving at the moment.  After I get the colors working correctly then I have to tackle the 16 meg memory limit of Android.  OpenXcom takes over 40 megs when running on my computer at home.

If anyone wants the APK to test just let me know and I can get it to you and tell you how to install the xcom files properly so it will run.  My brother has been running it on his Acer tablet and loves the work I have done.

Anyway, I hope I'm not stepping on your toes openXcom people, but I just wanted to do this for me.  It has been a learning experience.