Author Topic: Ocean colouring - Version 2  (Read 16047 times)

Offline pmprog

  • Commander
  • *****
  • Posts: 647
  • Contributor
    • View Profile
    • Polymath Programming
Ocean colouring - Version 2
« on: October 07, 2010, 01:38:33 am »
Patch - Includes a bug when _cntrLat = 0 will update this thread when fixed

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: Ocean colouring - Version 2
« Reply #1 on: November 14, 2010, 06:00:16 pm »
I got a new idea for the ocean rendering, so I figured I'd post it here.

Basically from a lot of messing around with commenting and profiling and different libraries, I figured out that:
- Rendering is cheap. Specially 2D rendering. Let's face it, the game refreshes the whole screen every tick (probably a lot more effort than it actually needs) and it still achieves hundreds of fps most of the time.
- Simulating 3D is expensive. All the polygons, the iterations, the calculations, the conversions, it's all a heavy load for the game to redo every tick, specially on low-end devices.

With that in mind, I thought of taking your approach in this thread - rendering the lighting on the ocean all at once - but from a 2D perspective. After all, the land needs polygons because it needs to draw out a detailed textured world, all with varying regions and terrains and lighting and stuff (and even that is a lot faster than the ocean currently is). The ocean doesn't, it's purely a visual aid, so there's no need for polygons, storing or calculating anything fancy.

With that in mind, here's the approach I thought up:
1. Draw the flat circle, either in the brighest or darkest shade (whatever's more convenient).
2. Calculate the "separator line" between the brightest/darkest shade and draw it out.
3. Go left-to-right top-to-bottom filling the circle area up to the "separator line", like a bucket fill.
4. TA-DA!

You could add more lines to get the smoother shading effect on the light edge. This is similar to your approach, but without using polygons, therefore:
- Polar-to-Cartesian calculations are kept to a minimum, as they're only needed for the "separator lines" which would have at most 10-20 points depending on how smooth you want them to be.
- No need to worry about the effect looking smooth on the circle edges, since the "bucket fill" approach would fill it all up with no issue.
- All the colouring is done at once at the pixel level, with no need for tons of iterating and rendering.

Thoughts?

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: Ocean colouring - Version 2
« Reply #2 on: November 14, 2010, 06:08:14 pm »
looks good, if the filling method is fast enough. Is that a method you write yourself, or does it exist?
And  and wouldn't you need 16 seperator lines? I think the original one had 16 shades of blue.

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: Ocean colouring - Version 2
« Reply #3 on: November 14, 2010, 06:16:44 pm »
There is no built-in "fill" method, you'd have to go through the surface pixel-by-pixel filling along the way, but that's actually faster than it looks. All the shape drawing is done like that (a whole bunch of stacked horizontal lines), and the game already does a bunch of pixel-effects across entire surfaces with little issue. If you were really clever you could even write your own shaded-circle routine and have no need for the initial base circle.

And the original only has 5 separator lines as seen here: https://openxcom.ninex.info/forum/index.php?topic=105.0 (and even 16 lines would probably a lot less calculation-intensive than the hundreds of polygons the ocean is currently made of :P)

Offline pmprog

  • Commander
  • *****
  • Posts: 647
  • Contributor
    • View Profile
    • Polymath Programming
Re: Ocean colouring - Version 2
« Reply #4 on: November 19, 2010, 11:50:46 pm »
Sorry it's taken so long to come back. Life's been pretty busy.

Sup, you're post is exactly the way this new version worked, but as I calculate the line and edge of the globe, I just do a single polygon draw.

If you looked at my patch, should actually be quite easy to tag on your "fill" method instead
« Last Edit: November 19, 2010, 11:53:42 pm by pmprog »

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: Ocean colouring - Version 2
« Reply #5 on: December 23, 2010, 04:50:39 am »
Finally had a chance to integrate and try out your patch. Very impressive, even without my "fill method" it's still a lot faster than the current method.

As for your _cenLat = 0 bug, I found a stray line in your code that was doing nothing but drawing uninitialized garbage, so I commented it out:
Code: [Select]
if (!pointBack(hackDay, hackDayLat))
{
polarToCart(hackDay, hackDayLat, &x, &y);
polyPointsX.push_back(x);
polyPointsY.push_back(y);
https://drawPolygon(dx, dy, polyPointsX.size(), Palette::blockOffset(12) + colourShift);
}

With that out of the way everything seemed to work fine, so I cleaned it up and committed it, even got those scary dynamic arrays working. :P Even if there's still any issues you wanna work on it, I figure this way it'll be easier for you to do.

Offline pmprog

  • Commander
  • *****
  • Posts: 647
  • Contributor
    • View Profile
    • Polymath Programming
Re: Ocean colouring - Version 2
« Reply #6 on: December 23, 2010, 08:26:19 am »
Great news. I would seriously like to get back on board and assist you some more on this, I'm just really struggling to find time.

Fingers crossed for the new year

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: Ocean colouring - Version 2
« Reply #7 on: December 23, 2010, 11:26:22 am »
Hi,
I have a little performance suggestion, but it probably will not be worth the effort :p
I see you recalculate sin(_cenLat) and cos(_cenLat) a lot of times over and over again.
You could however calculate and store the sin and cos in results in _sinCenLat and _cosCenLat only at times when _cenLat changes. And then use this precalculated value in the code. It eliminates a few hundred sin/cos calculations.
It may be of use on a Dingoo... because on a PC you probably not feel the difference, I don't know, I thought I'd just share my idea.

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: Ocean colouring - Version 2
« Reply #8 on: December 23, 2010, 01:33:59 pm »
I think it's worthly to investigate. Maybe on dingoo it will speedup game.

Offline pmprog

  • Commander
  • *****
  • Posts: 647
  • Contributor
    • View Profile
    • Polymath Programming
Re: Ocean colouring - Version 2
« Reply #9 on: December 23, 2010, 01:38:39 pm »
I have a little performance suggestion, but it probably will not be worth the effort :p
That would require very little effort to implement, and probably would be worth it.
However, it's worth considering memory overhead for having those variables. Okay, so two values won't take an awful lot, but it might be worth keeping them local to the draw proc, and just calc them at the top of the function. Kinda of a halfway house - Only using memory when needed, but reducing the calculations needed

Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: Ocean colouring - Version 2
« Reply #10 on: December 23, 2010, 01:47:52 pm »
I have a little performance suggestion, but it probably will not be worth the effort :p
That would require very little effort to implement, and probably would be worth it.
However, it's worth considering memory overhead for having those variables. Okay, so two values won't take an awful lot, but it might be worth keeping them local to the draw proc, and just calc them at the top of the function. Kinda of a halfway house - Only using memory when needed, but reducing the calculations needed
Fair enough, having these as class member variables may also people making them wonder what they are for. Having them locally it is more clear, and less codechange needed.

By the way, the performance increase of the new ocean colouring is amazing. On my pc rotating/zooming the globe goes very smooth and the overall FPS is also increased. Great job guys.

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: Ocean colouring - Version 2
« Reply #11 on: December 23, 2010, 02:14:38 pm »
The new coloring is totally broken, at least for me. A bit later I'll post a bug report with detailed screenshots. Perhaps you'll be able to reproduce it if you move the viewport with rmb and set timer to 30 min.

Offline bramcor

  • Captain
  • ***
  • Posts: 76
    • View Profile
Re: Ocean colouring - Version 2
« Reply #12 on: December 23, 2010, 03:15:01 pm »
Marabus: I see the day/night gradient is broken in some special cases, but it is only slightly worse than before ;)

Happy news is I went from ~40fps to ~60fps in geoscape view.

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: Ocean colouring - Version 2
« Reply #13 on: December 24, 2010, 05:09:57 pm »
but it is only slightly worse than before ;)
I beg to differ - just updated a bug report with a video ;)

Offline bramcor

  • Captain
  • ***
  • Posts: 76
    • View Profile
Re: Ocean colouring - Version 2
« Reply #14 on: December 25, 2010, 04:19:29 pm »
but it is only slightly worse than before ;)
I beg to differ - just updated a bug report with a video ;)

Just saw the video - that is pretty bad.

I have only experienced the right-side error, with gradient lines being spaced apart by strange intervals.

The left-side flickering of dark areas I have not seen before, hence the "only slightly worse than before" comment ;)

I will have to figure out how to replicate it!