@mvi e-Mailed me some private source code (thanks) I can harvest the shroud rendering from. We currently use a 24x24 → 32x32 rescaled version of the RA shroud sprites for d2k which is ugly.
I am just used to this workflow. It is a public TODO item I made for myself so I don't forget. I have a lot more tasks assigned to myself. Most of them in private GitHub repositories because my company also uses these trackers to keep an overview of what everyone is working on.
C&C and TS shroud, too.
It seems we already have what we need. @mvi's tool defines a referenced palette (custom palette inside DATA.R8, but not inside the same image frame as it is shared with other frames). I believe the Dune 2000 shroud palette would be
because it is the nearest neighbor which got a paletteOffset defined. However we use a self-made hard-coded ShroudPalette: that I don't understand.
Also ShroudRenderer despite being extremely hard-coded to shadow.shp and this sequence array, I can't even find matching tiles for shadow.shp and http://content.open-ra.org/index.php?p=detail&table=units&id=164 so the fog jigsaw puzzle ended before it even started.
I did not know that we do not even support the TD shroud tiles (and that they differ). TS shroud depends on isometry which we also don't have so I think these are separate issues.
D2K only uses 4 bits for defining shroud state (5 if you count the tile itsef), based on the diagonal neighbours. This gives 14 distinct tile types, each with four variants to reduce repetition (cf. #3024).
This will be easy to implement, but probably wants to wait until after we fix the other problems with the shroud.
C&C does the same thing, but only defines 3 variants of each type. It looks like RA is the outlier here.
New shroud renderer. Fixes #2162. Fixes #3024. Fixes #4034.
Uses the original tile sprites in C&C and D2K and uses a smoother transition in all mods.