In development: Water with depth

[Andrew350]

Overlay was perhaps a bad choice of word, I really just meant "do it in 32bpp". i.e. make the sprites darker in 32bpp color depth so when applying the water cycle colors as a mask they will be slightly darker but otherwise look the same. Basically the same way I did with NightGFX (but obviously not with the same amount of darkness )

It would be trivial to do this way, but obviously it requires going 32bpp for these particular sprites, which may not be desired in the "base" base sets, if that makes sense.

Quoting myself for relevance

In effect you could achieve something like this:

Suhead Transport, 01_02_19303#1.png

(610.45 KiB) Not downloaded yet

Obviously this is just a quickie, so the effect could probably be toned down a bit, but you get the idea The same thing could, in theory, be done to the original graphics as well, but only by utilizing 32bpp. Pure 8bpp is going to be trickier to keep the water effect while showing depth in an obvious way like that^ (maybe not impossible though)

[wallyweb]

Sorry, I can barely tell any difference between the three shallow/medium/deep sprites. Is it at all possible to mix some other colours in between the palette cycled ones to get slightly more green-ish or dark-feeling tiles?
But I'll see if I can add a NewGRF feature for water tiles, or maybe rather extend the existing feature for rivers and canals, so the sprites can get in the game properly.

I can play with the wave cycle density variation for better definition.
Adding green pixels to the sprites is too pixilated to be of any use.
Another option, probably the better one, is to modify the palette itself.
OTTD's palette is defined in src/table/palettes.h
Look for "dark blue water".
There are five values in r,g,b format.
modify the g and b values so that g > b
Modify the table structure to add three more "dark blue water" sequences: "dark blue water low" "dark blue water medium" "dark blue water deep"
CAUTION: Verify your revised/new rgb values to make sure they are not already in use in /* regular colours */.

If you have images of the shades of green that you are looking for, I can use my colour picker to get the proper rgb values.

[planetmaker]

Adding in different colors will be difficult for OpenGFX, since the whole sprite is one rolling wave effect with the water cycle. It would likely need to be redone entirely to make this work cleanly, but will need some experimenting to find out. It would be a lot easier if we could use a 32bpp overlay to simply darken the wave cycle colors...but that probably isn't something we want for the 8bpp base sets I'm guessing?

Actually that's an approach which could be done. Even for 8bpp sprites, everything is rendered by default in 32bpp as 8bpp does not work pretty on modern graphics cards. So such post-processing should be feasible. And it could be disabled when actual 8bpp is only available... thus uniform water colour like so far on antique hardware (I wonder whether even 1% of users will notice )

[jfs]

wallyweb: I implemented depth water sprites and made a test using your first demo.

openttd_2020-01-14_16-55-58.png (129.94 KiB) Viewed 1839 times

Here's the sprites I added to your NFO file:

Code: Select all

// Action 5 - new base set sprites
   79 * 19   05 19 04   01 00 00 02  02 02 02 02  02 02 03 03  03 03 03 03
   80 sprites\WaterCycleTest.png  16 112 09 31 64 -31 0  // normal
   81 sprites\WaterCycleTest.png  96 112 09 31 64 -31 0  // shallow
   82 sprites\WaterCycleTest.png  176 112 09 31 64 -31 0 // medium
   83 sprites\WaterCycleTest.png  256 112 09 31 64 -31 0 // deep

This action 5 uses feature 0x19 and can specify from 1 up to 16 sprites that can be used as replacement flat water tiles.
Format: <sprite-num> * <length> 05 19 <num-sprites> <translation-table>
num-sprites is the number of replacement sprites following.
translation-table is 16 bytes translating each of the 16 depth levels (from shallowest to deepest) into one of the new sprites that follow the action. Can also use FF for entries to use the base-set flat water tile.

In this example, depth 0 uses the "shallow" sprite, depth 1 and 2 use the "normal" sprite, depths 3-9 use the "medium" sprite, and depths 10-15 use the "deep" sprite.

Edit: I've just added a Windows build of my current branch.

[wallyweb]

This action 5 uses feature 0x19 and can specify from 1 up to 16 sprites that can be used as replacement flat water tiles.

I like the elegance. Authors can simply use sprites of their own design.

[andythenorth]

That's looking pretty good. I think we might want transition tiles also, it's just a dither between each state imho, wondering if that could be automated.

[wallyweb]

That's looking pretty good. I think we might want transition tiles also, it's just a dither between each state imho, wondering if that could be automated.

Easily done with my wave cycle pixels. The normal tile has 20 wave cycle pixels. My deep one was a bit overdone with 60.
60-20=40
40/16=2.5
So, normal at 20, transitions +2 increments, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50 should be interesting.

[Andrew350]

So, normal at 20, transitions +2 increments, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50 should be interesting.

There is no way you'd be able to see that small of a difference in the game though. As it is the difference between shallow and deep is only noticeable because of the sharp line between them. Put even a single transition tile between them and the difference will be very hard to spot unless you're counting pixels

[wallyweb]

So, normal at 20, transitions +2 increments, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50 should be interesting.

There is no way you'd be able to see that small of a difference in the game though. As it is the difference between shallow and deep is only noticeable because of the sharp line between them. Put even a single transition tile between them and the difference will be very hard to spot unless you're counting pixels

Another thought ... wave action is usually heavier over shallower water, especially close to shore.

[jfs]

Yes, maybe try making versions with more or fewer of the pixels that cycle to the bright white, with the more calm ones for deeper and the more frothy ones for shallow depths.

[Andrew350]

Well, I give up. I was going to "quickly" whip up a test grf with 16 levels of darker water to see what it looked like, only to get absolutely stifled trying to make 32bpp work in NFO

I feel like I'm so close but I just can't seem to coax grfcodec into encoding the 32bpp sprites. Even though everything seems to be syntactically valid from what I can tell, it only wants to pick up the 8bpp sprites. I must be missing something simple. Anyway maybe someone else can figure out where I'm going wrong and compile it to see what the sprites look like in-game, here's the files:

[jfs]

Well, I give up. I was going to "quickly" whip up a test grf with 16 levels of darker water to see what it looked like, only to get absolutely stifled trying to make 32bpp work in NFO

I feel like I'm so close but I just can't seem to coax grfcodec into encoding the 32bpp sprites. Even though everything seems to be syntactically valid from what I can tell, it only wants to pick up the 8bpp sprites. I must be missing something simple. Anyway maybe someone else can figure out where I'm going wrong and compile it to see what the sprites look like in-game, here's the files:

I don't quite get any errors encoding your NFO file with GRFCodec 6.0.6 r991, although it gives two non-fatal warnings. However it does seem it doesn't encode the 32bpp sprites and I don't know anything about that either.
However your action 5 is also wrong, you specify FF for the number of replacement sprites, the correct value is 10 (or \b16) for a full set, so the GRF fails to load for that reason.


Edit: Figured it out, you also need to run grfcodec with the "-g 2" parameter
So the total commandline is: grfcodec.exe -e darkwater.grf -g 2
There's something weird about some of the sprite offsets though.

Edit 2: I got everything working, attaching the fixed NFO file. You also had one of the sprite offsets wrong causing HoM effects for depth 10.

[wallyweb]

Here we go again

A new tar ...

Wave Cycle for Action 5 Depth.tar

(68.5 KiB) Downloaded 77 times

Adds a new Action 5 scenario
Adds a new Action 5 GRF with NFO.
Revises the previous GRF, NFO and spritesheet.

What it does:
Both GRFs can be loaded together.
Revises the wave sprites to:
- shallow (lots of waves - 40 pixels)
- medium (fewer waves - 20 pixels )
- normal (the new normal - 10 wavy pixels)
- deep (very calm - 5 pixels)

TO DO:
- Add ActionA to change coast corner tiles water to match shallow
- Redraw all tiles to get more even wave action so as to reduce or eliminate obviousness of tile edges

Sorry, no screenshot. Load the Action 5 scenario for a do-it-yourself screenshot.

[jimbob]

Any idea how this might work with demolishing the tile to reveal ground? Or lowering dry terrain below sea level? If those work you'd get chunnels to work without the hacky way the patch pack handles it.

[jfs]

The way this does "depth" is not the same way Roller Coaster Tycoon or Locomotion do depth, it's very much faked in this patch.
Sea level is still terrain height zero, there is nothing below height zero. Water tiles just have some extra data for their "depth", that certain things can choose to let affect them.

Demolishing a deep water tile still just turns it to a regular ground tile, although it might cost a lot more. The surrounding water tiles also don't change depth when you do that, so it's like you just pounded a solid pillar of dirt into the water. If the cleared tile then floods again (if it's at sea level and the surrounding tiles are sea tiles) it will be depth zero (shallowest) regardless of its original depth or the surrounding tiles' depth.
I have added a mechanism that slowly evens out depth, generating an even gradient from the coast and out, but it takes many years of game time.
All in all, very simplistic and unrealistic.

Nothing really helps with making underwater tunnels easier or harder here, although you can potentially make them "more interesting".

[Andrew350]

I don't quite get any errors encoding your NFO file with GRFCodec 6.0.6 r991, although it gives two non-fatal warnings. However it does seem it doesn't encode the 32bpp sprites and I don't know anything about that either.
However your action 5 is also wrong, you specify FF for the number of replacement sprites, the correct value is 10 (or \b16) for a full set, so the GRF fails to load for that reason.


Edit: Figured it out, you also need to run grfcodec with the "-g 2" parameter
So the total commandline is: grfcodec.exe -e darkwater.grf -g 2
There's something weird about some of the sprite offsets though.

Edit 2: I got everything working, attaching the fixed NFO file. You also had one of the sprite offsets wrong causing HoM effects for depth 10.

Oh hey, didn't see your edits before, glad you found the issue! Some of those numbers were "intentionally" off from me messing around trying to get it to do something. Specifically when I decoded NightGFX for example, the NFO output had "FF" as the sprite count for every action 5, so I thought maybe that had some significance somehow. I was trying anything

Where did you find that -g parameter? Obviously I looked through the documentation that ships with grfcodec but I can't find any mention of that anywhere

Now that I can compile it for myself and see the sprites in-game the OpenGFX ones seem a little...lacking? Maybe those need to be darkened more. The original graphics came out slightly better, but also seem to not show enough variation except in extreme depths (IMO):

Unnamed, 01_01_19303#1.png

(782.83 KiB) Not downloaded yet

I don't know which approach looks better to be honest, most water ends up shallow and neither art style really shows much variation in that case. I do like the "smoother" transitions with 16 types though

[wallyweb]

UPDATE
======
I messed up. I used the default sprites from TTD/TTDP.
I have switched to the OpenGFX sprites which are GPL.

After considerable testing (fiddling around) I made some changes.
I found some windows palette 8bpp non-cycling colours that approximate the water cycle colours:

WaterDepth.png (1.52 KiB) Viewed 1328 times

1. The wave cycle sprites are too difficult to manage.
2. The default water cycle sprites cycle too fast to be useful.
3. Andrew350's solid sprites idea seemed more appropriate so I stole erm, borrowed it.
I used the first four non-cycling sprites from the above sample.
I could have used all eight, but I thought that would be too much.
The coast tiles have been modified to match the shallow tiles while keeping the waves breaking onto the beach.
Here is a grf with all the action:

WaterDepthAction5Test.grf

(7.31 KiB) Downloaded 74 times

If these look acceptable, I can set up parameters so that the player can:
1. Turn them off in favour of the default sprites
2. Optionally select the 8 colours. (Is this really needed?)

EDIT: Y'all will probably want the nfo and the sprite sheet

WaterDepth.tar

(26 KiB) Downloaded 58 times

[Andrew350]

I messed up. I used the default sprites from TTD/TTDP.
I have switched to the OpenGFX sprites which are GPL.

Hmm, yeah license is kind of an issue for making matching sprites to ship with the game for the original baseset. We'd almost have to redraw all the water tiles new, but closely enough to the originals to not be too jarring/obvious for longtime players. I'm pretty sure people who prefer the original graphics aren't going to like all the water suddenly switching to OpenGFX-style with this new feature

By the way, I tried your test grf but all the water is just solid colors, was that intended? I haven't looked into your .tar yet, so just wondering if I missed something.

[wallyweb]

Hmm, yeah license is kind of an issue for making matching sprites to ship with the game for the original baseset. We'd almost have to redraw all the water tiles new, but closely enough to the originals to not be too jarring/obvious for longtime players. I'm pretty sure people who prefer the original graphics aren't going to like all the water suddenly switching to OpenGFX-style with this new feature

Yea ... I'm one of those who prefers the original graphics, hence my mixup.

By the way, I tried your test grf but all the water is just solid colors, was that intended?

Yes. Deep is dark, light is shallow, two in between. As noted above, the water cycle is too wonky. There are only five shades available so it is impossible to have variations for several depths. Adding the wave cycles, à la original, just makes it worse.

I haven't looked into your .tar yet, so just wondering if I missed something.

Yep.
Look at the sprite sheet. There is an eight colour option that I haven't coded yet. What do you think? Should I add a parameter so that the player can choose between 4 and 8 with a normal water default?
These are all 8bpp. I think you suggested 32bpp. Any reason that couldn't be offered as a third parameter?

[Andrew350]

What do you think? Should I add a parameter so that the player can choose between 4 and 8 with a normal water default?
These are all 8bpp. I think you suggested 32bpp. Any reason that couldn't be offered as a third parameter?

Er, I have to be brutally honest, I'm not really liking the 'flat' water idea at all It just doesn't have any character or liveliness to it, I want to see some palette animation

The whole reason I suggest going 32bpp is exactly the reason you mention: the 8bpp palette is too restrictive to get a good result here Your first attempt was ok, but then obviously there's the problem of redistribution, which takes that option away. As I write this I'm playing around with trying to make a "stock-alike" water sprite from scratch which blends in decently with the original shore sprites, but the palette animation cycles are a real pain to line up with their 'randomness', so we'll see if I can get a good enough result. If that works then more options may be on the table

I'd still lean towards going 32bpp and using the darkening effect even if this works, but that's just my preference.