aliens

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

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #45 on: September 22, 2011, 07:44:15 pm »
i have probably great idea of speeding up globe drawing.

https://on init:
we need create 2 big tables that store hight of sphere (around 200x200). both spheres have different radius (smaller have size of earth in geoscape)
https://per frame
create "shade" buffer.
made some offset (in `x`, `y` and `z` axis ) between this two spheres
we test relative hight of them
Code: [Select]
if(hight_a[x][y] <= hight_b[x+off_x][y+off_y] + off_z)
if this test pass increase shade value in buffer.
Code: [Select]
    buffer[x][y] += 1;
repeat this with different offset to create darken shadows

now when we bliting ocean to surface we add shade from buffer
Code: [Select]
surface[x][y] = OCEAN_COLOR_OFFSET + buffer[x][y];
(this can be used for shading lands too)

only problem i have with this is that work only with max zoom out globe.
to this work with `zoom in` we need
a) bigger tables (probably pointless)
b) interpolate hight (around 3 + 3 multiplates per screen pixel every frame)
c) live with big square shadow when we zoom in :)

i did somthig similar when i have fun with "universal blit function" :)
https://img21.imageshack.us/img21/2985/outqm.jpg
https://img3.imageshack.us/img3/1566/outjs.jpg

every shpere is flat bitmap but I store height of every pixel, and I use it for drawing.
this image was generate in 1/60s, when we reduce number of spheres (in this pix is around 40) we can draw this even faster
 

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
    • Email
Re: Android Port
« Reply #46 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?

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #47 on: September 22, 2011, 10:20:46 pm »
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.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2163
    • View Profile
    • Email
Re: Android Port
« Reply #48 on: September 23, 2011, 12:11:00 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 :)
I only cache the converted coordinates. Caching the graphics would be kinda pointless since they change every game tick (more or less).

Is it the calculations for the shading polygons that takes the longest or actually shading and drawing them?
A little of column A, a little of column B.

See, the land is easy. It's just a bunch of fixed polygons on a 2D map, so we convert them to pseudo-3D with these scary formulas, shade them, draw them, done! The drawing is simple and the recalculating is simple and only needs to be done when the globe moves.

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 :P and nobody's figured out a fast way of doing it yet.

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #49 on: September 23, 2011, 12:42:40 am »
SupSuper how are stored rotation of globe in `Globe` class?
we have this:
Code: [Select]
double _cenLon, _cenLat, _rotLon, _rotLat;what is meaning of each of this fields?

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
    • Email
Re: Android Port
« Reply #50 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...

Offline Putz1103

  • Sergeant
  • **
  • Posts: 12
    • View Profile
    • Email
Re: Android Port
« Reply #51 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 :P 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)

Offline DaiShiva

  • Sergeant
  • **
  • Posts: 39
    • View Profile
Re: Android Port
« Reply #52 on: September 23, 2011, 01:56:30 am »
When I had made a simple viewer to look at the map, I treated the datafile as a description of a 3d object, and then used 3d camera matrices to view it from different angles. I cheated and just drew 2d polygons (no z-value) from the rotated earth though.

For ocean, you can use the tftd data file.
« Last Edit: September 23, 2011, 01:58:24 am by DaiShiva »

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2163
    • View Profile
    • Email
Re: Android Port
« Reply #53 on: September 23, 2011, 03:21:08 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.
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:
Code: [Select]
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 :P 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 :P) 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! :o

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #54 on: September 23, 2011, 03:43:51 am »
_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.
what vales `_cenLon` and `_cenLat ` have when globe is flipped upside down?

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #55 on: September 25, 2011, 03:31:04 am »
strange when i dont draw ocean i have less fps.

I run some test with my function
I put 100 shade function in loop and only 100 fps less (from 1300).
what is slowest part of globe drawing?

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2163
    • View Profile
    • Email
Re: Android Port
« Reply #56 on: September 25, 2011, 04:22:36 pm »
_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.
what vales `_cenLon` and `_cenLat ` have when globe is flipped upside down?
_cenLat would be -PI or PI I think.

strange when i dont draw ocean i have less fps.

I run some test with my function
I put 100 shade function in loop and only 100 fps less (from 1300).
what is slowest part of globe drawing?

I don't know what super-computers you people have :P but here are my average FPS with Release build:
- Drawing everything: 700 (600 when rotating)
- Drawing without ocean: 850 (650 when rotating)
- Drawing without land: 800 (600 when rotating) - seems to vary a lot depending on globe position
- Drawing without land and ocean: 900 (800 when rotating)

The differences are probably more noticable on low-end hardware. But if you have come up with a more efficient / nicer method for drawing the globe, feel free to share. :)
« Last Edit: September 25, 2011, 04:29:13 pm by SupSuper »

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #57 on: September 25, 2011, 04:38:53 pm »
i tested this with original rez (aka 320x200).

Offline Yankes

  • Commander
  • *****
  • Posts: 2540
    • View Profile
Re: Android Port
« Reply #58 on: September 25, 2011, 05:54:40 pm »
double post :D now some progress :)
simple test show that this is slower than normal, but i use full gradient of ocean shades (not 4, but all 32) and I can use this same function to shade lands too (without any big changes)
and i can always reduce number of shades used.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2163
    • View Profile
    • Email
Re: Android Port
« Reply #59 on: September 26, 2011, 01:58:44 am »
Looks very cool, though it's not all about speed, make sure there aren't any peculiar issues with peculiar positions and the like, they always seem to pop up on the globe :P (eg. current ocean doesn't like (0,0) position among other things).