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.
Well I'm not sure how your conversion process is, if you initially just crudely converted every file to Java and took it from there or something. Since it's a completely different codebase you can't take direct advantage of the version control features of easy merge/branch/etc. If you only want an overview of what's changed you can probably diff between different revisions of the codebase (eg. from your June 3rd version to now) and take it from there. Most changes only happened in the Battlescape folder anyways (and also Engine for optimizations).
SupSuper how are stored rotation of globe in `Globe` class?
we have this:
double _cenLon, _cenLat, _rotLon, _rotLat;what is meaning of each of this fields?
_cenLon / _cenLat are the longitude / latitude of the point currently shown at the center of globe. These control the rotation of the globe.
_rotLon / _rotLat are the amount of "rotation speed" on longitude / latitude currently being applied to the globe. So while you hold down one of the rotation buttons, _cenLon += _rotLon and _cenLat += _rotLat.
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)
Longitude strips were the original shading method, but you need to have an absurd amount of "strip polygons" with an absurd amount of points to create a smooth shading effect. Not to mention such huge polygons cause lots of annoying wrap-around end edge-crop bugs (unlike the land which is made of small manageable 3-4 point polygons).
This was later replaced with the current method, draw a circle of the most visible shade (day/night) and then calculate and draw a single huge polygon on top of it for the visible part of the opposite shade. Not a perfect solution (the flickering edges are the most obvious issue) but much nicer than before.
If that's not clear, I will explain the full history and workings of the globe later (probably in a different thread since we've basically hijacked sir_nacnud's thread
) since it's long and it's late and you've gotten me rambling enough as is.
But yes performance-wise, the water shading is probably the biggest offender. For laughs, roll back to the earliest versions and behold as the globe actually performs smoothly!
