Well, it doesn't work so well for static, nonfalling magma, which there's sure to be much of in established forts.
The solution is one something like the ramp code, checking neighboring(UDNSEW) tiles for the same liquid (water if water, lava if lava) or walls and, possibly using the seventh bit for ground underneath separately from water underneath.
Waterfalls aren't going to look nice until you make the lesser tiles adhere and possibly cohere (since the code and art are going to be so similar). Check six five- way-occupancy(NSEWUD) for (solid) and (water), choose art based on that and 'depth'. Then, a waterfall will cling to the surface it's falling along, and you won't get the "pancake effect". Of course, one can take this anywhere from simple (is_occupied, 448 arts maximum) to crazy (checking each adjacent tile's answer to this algorithm) in terms of code and art to sink into it.
It'll be a hell of a lot faster to just render these things than to draw, that's for certain.
E = ESN, W = WSN, S = SEW, N = NEW
actually, hmm. What re the important cases we can get away with doing? Waterfalls aren't guaranteed orthogonal, so the waterfall cases of eight directions plus the shower case (water to up, no solids adjacent). Can fairly ignore the wide showers, as multiple streams won't look that bad. Hmm...how much trouble could we be in in the crazy... 7^6 = 117649
Perhaps this is not the visualiser for the grand water treatment. Still, fixing the pancake effect is easy to fix in six cases (take 7/7 tile, move a different surface away from its edge gradually to make 6-1, or notice that certain diagonals are parallel to the view for the two easy diagonls) and reasonable in the other two (need a flat-to-viewer surface to use)...
//where are my tri-state bitmatch operators when I need them. Should be able to generate a LUT for this, but this is easier for me to read.
if (depth == 7)
tileindex=normal_tile;//no biasing on a full tile, skip checking.
else
directions_occ = directionmask;
switch(directions_occ){
/*
case __UDNSWE
0 = unoccupied, 1 = occupied by wall or at least 1 water
U/D case is pretty much "is there a floor here/above here" bridges...ugh, bridges would be difficult. But they're in setting directions_occ, not using its results.
*/
case 00xx0001:
case 00xx1101: tileindex=cling_east;break;//E!NSW ~ NSE!W. Can be changed later if/as more art arises.
case 00xx0010:
case 00xx1110: tileindex=cling_west;break;//W!NSE ~ NSW!E, "
case 00xx0100:
case 00xx0111: tileindex=cling_south;break;//S!NEW ~ SEW!N, "
case 00xx0101: tileindex=cling_southeast;break;
case 00xx0110: tileindex=cling_southwest;break;
case 00xx1000:
case 00xx1011: tileindex=cling_north;break;//N!SEW ~ NEW!S, "
case 00xx1010: tileindex=cling_northwest;break;
case 00xx1001: tileindex=cling_northeast;break;
case 00010000:
case 00011111: tileindex=normal_tile;break;
case 00100000:
case 00101111: tileindex=invert_tile;break;
case 0011xxxx: tileindex=trickle_tile;break;
default: tileindex=normal_tile;break;}
grab_tile(tile, depth);
a thought. What's stonesense do right now in the ramp+water case? Ramps would present an easy(Ha) case of stealing their calculations and surfaces.
edit: Can't for the life of me remember (or find) what the "this number is binary" prefix for C++ is, or if it exists. 0b?
But, this reminds me of the issue of ramp tiles with water. Which would take rather many sprites, unless you figure out something.
Anyone know how it works presently? I suspect "it doesn't" due to neither binary draworder working nicely- cyclical overlap.
Given prior optimisations in the ramp code I'm sure you'd use a
LUT instead of the pseudocode suggestions I wrote above.
But, if we ignore the ramps for now, then one can get away with a mere 60 new sprites. You'd only need draw 6 really once you get that diagonal face drawn, as prisms would do for all but the TRICKLE_TILE case (that is, water falling that has no adjacent walls) and those prisms can simply be drawn by C+Ping the faces and cropping and such.
Of course this is really a probllem you can throw an arbitrary quantity of sprites at.
On the side, my calculations put
Sevenths | Sixteenths nearest | Height used in spritesheet presently |
? | | 0 |
1/7 | 2/16 | 2 |
2/7 | 5/16 | 4 |
3/7 | 7/16 | 7 |
4/7 | 9/16 | 10 |
5/7 | 11/16 | 13 |
6/7 | 14/16 | 16 |