ZDoom

Looks good to me. I was probably going to do something similar to that but I hadn't gotten around to it.

I reworked applying of customized invulnerability colormap in [url=https://github.com/coelckers/gzdoom/pull/1021]this PR[/url]. Testers and reviewers are welcome.

The code I added just tries to what the hardware renderer does already.

That said, I don't understand why the colormap shader reduces it to a blend when it could have uploaded the special colormaps as textures and applied them as a LUT. Is it just how the code evolved historically or there a deeper reason?

The problem is in loosing all colormaps (except five hardcoded) added with [b]AddSpecialColormap()[/b]. At least, [b]R_InitColormaps()[/b] cannot be used to apply custom invulnerability colors.

Looks like dpJudas [url=https://github.com/coelckers/gzdoom/commit/e68b46cb6af371b336fe6f18e6bd491ebf62375b]snuck this in[/url] so now all that remains is for me trying to fix the custom colormaps, themselves... if I can find the code that activates them.

That's because it's not been done at all on SoftPoly. I was referring to OpenGL/Vulkan, there's more than one issue here.

[quote="Rachael"]Okay, from my test, it appears that this problem only occurs if you turn the custom invulnerability colormap on. If you have it off from the very moment you start GZDoom, it does not appear to occur.[/quote]

I can not confirm this. For me, running on softpoly, the Colormap simply doesn't work. This is on an installation that has never even touched the custom setting.

Okay, from my test, it appears that this problem only occurs if you turn the custom invulnerability colormap on. If you have it off from the very moment you start GZDoom, it does not appear to occur.

For the record, I took that picture while in OpenGL mode. But [u]not[/u] when using Vulkan.

I'm not sure if SSE2 is capable on operating on a byte target. The best course of action might be to create an 18 bit lookup table and then let 3 or 4 threads run over the image, translating each pixel. Doing such a uniform transformation ad-hoc per pixel may just be too slow.

This is probably a NYI thing in SoftPoly. Keep in mind the shader functions in SoftPoly are [i]extremely[/i] time-sensitive - every new check or function you put in here will likely result in a FPS hit even when they are not active.

I think I could code in a colormap shader pretty easily, but I don't trust myself to be able to optimize it well, because I tend to favor code organization and moddability over speed. This probably needs dpJudas's SSE2 methods.

Works fine using OpenGL and Vulkan.
[attachment=1]Screenshot_Doom_20200114_110531.jpg[/attachment]It works incorrectly with SoftPoly though.
[attachment=0]colormap_softpoly.jpg[/attachment]

class InvS : PowerupGiver
{
	Default
	{
		+COUNTITEM
		+INVENTORY.AUTOACTIVATE
		+INVENTORY.ALWAYSPICKUP
		+INVENTORY.BIGPOWERUP
		Inventory.MaxAmount 0;
		Powerup.Type "PowerInvulnerable";
		Powerup.Colormap 0.0, 0.0, 0.0, 1.0, 1.0, 1.0;
		Inventory.PickupMessage "$GOTINVUL";
	}
	States
	{
	Spawn:
		PINV ABCD 6 Bright;
		Loop;
	}
}

[code]class InvS : PowerupGiver
{
Default
{
+COUNTITEM
+INVENTORY.AUTOACTIVATE
+INVENTORY.ALWAYSPICKUP
+INVENTORY.BIGPOWERUP
Inventory.MaxAmount 0;
Powerup.Type "PowerInvulnerable";
Powerup.Colormap 0.0, 0.0, 0.0, 1.0, 1.0, 1.0;
Inventory.PickupMessage "$GOTINVUL";
}
States
{
Spawn:
PINV ABCD 6 Bright;
Loop;
}
}[/code]

"Give InvS" in console. You'll see no colormap is applied. This is most likely related to the InverseMap changes that were made.