ID:2607298
 
Not Feasible
Applies to:DM Language
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
Unsure of the viability of this (or if filters is the best means of implementation) but I would really like this sort of functionality. I know you can swap colors with the old icon procs but I'd rather not use them if I can help it.

(I know about color matrices but my use case requires precision)
A palette-swap filter should probably take an associative list of old color => new color.

Taking a proc would be nice, but then it would have to be a custom client-side proc, and those aren't a thing.
Unfortunately this isn't feasible. Shaders simply do not handle quantized color well, and checking for a color match is complicated by premultiplied alpha. While it could be done for a single color, it's not a good idea, and doing it for multiple colors would require a fixed-length list and a most sophisticated form of lookup, and would be even less performant.

I think there's a more reasonable way to handle this, which is to split your icon so that the color you need to replace is isolated. Then a matrix will do everything you need to, and even better you could make those pixels white and simply multiply by the target color instead of needing a matrix at all, for the best performance.
Lummox JR resolved issue (Not Feasible)
I don't understand how this is unfeasible. Other engines are able to do this through their shaders, and even if it's not ideal I feel like there's no way it's going to perform worse than using the deprecated Icon procs or having every atom in the game be separated into 4-5 layers of icons (which is what I'd need to do to get the functionality I want here.)

I don't understand how this is unfeasible.

It's not. It just requires a Look Up Texture in the shader where you use the RGB color of the Texture2D node on the shader as a 3D coordinate space for resolving the output color from the input color.

The real problem with this is that it requires a 16MB LUT for each distinct palette unless you want to commit to branching, which murders shader performance.

Older systems handled this at the hardware level. Newer systems make such tricks pretty costly. Build it into the engine isn't unfeasible, it'd just be prohibitively difficult to do in a manner that wouldn't have more downstream caveats than benefit.
Actually, I've given this some more thought.

What if your shader is limited to a 16x16 texture, giving an upper maximum of 256 unique colors for the entire sprite, and we only use a single color channel to handle the lookup? Let's use the red channel for simplicity.

We could generate an output coordinate from the red channel:

r = 255 * in color.r;
px = r - floor(r/16);
py = floor(r/16);
out color = palette.sample2D(px,py);


This would solve images with fixed palettes, but that would mean that palletized graphics would need to have their own distinct shader in order to function without a branch.

In theory, you could get away with passing an array of rgba colors as though it were a texture into the shader, and converting the floor of the red channel to the array index or generate a texture2D on palette creation instead.