[r1231]Powerup.Colormap issues

[Major Cooke]

Is it me or does this seem to always give an inverse map color?

For some reason, the Powerup.Color works just fine, but Powerup.Colormap does not. It just gives the inverse map, and that's it.

Code: Select all

Actor SlimeyEffect : PowerupGiver //Don't get slimed, or else!
{
	Powerup.Colormap 0.0, 0.0, 0.0, 1.0, 1.0, 0.0
	+INVENTORY.AUTOACTIVATE
	Inventory.MaxAmount 0
	Powerup.Type "OfSlimey"
	Powerup.Duration 2100
	//Powerup.Color GoldMap
}

Actor PowerOfSlimey : PowerProtection
{
	DamageFactor 1.15
}

[Gez]

The result is the same as in ZDoom, so this is not a GZDoom bug but a ZDoom one.


The problem is a bit of a catch-22. Here's what's happening.

There's a function called AddSpecialColormap which is used to create colormaps and add them to a list. It starts by checking to make sure the colormap isn't already found in the list to avoid needless duplication. Of course, the list starts up empty. It is filled during initialization of the graphic subsystems. This is what happens (among a lot of other stuff) when the start screen shows the message "R_Init: Init Doom refresh subsystem." Okay so far? Great.

When a Power.Colormap property is parsed, AddSpecialColormap is called.

Actor properties are parsed when actors are loaded. This happens when the start screen shows the message "LoadActors: Load actor definitions."


Now guess what happens? That's right. Actors are loaded before the R_Init stuff takes place. So here your custom colormap gets to be the very first one created, and receives index 0 for this honor. Now R_Init happens.

Code: Select all

void R_Init ()
{
	atterm (R_Shutdown);

	StartScreen->Progress();
	V_InitFonts();
	StartScreen->Progress();
	R_InitColormaps ();
	StartScreen->Progress();

	R_InitPointToAngle ();
	R_InitTables ();
	R_InitTranslationTables ();
	R_SetViewSize (screenblocks);
	Renderer->Init();
}

R_InitColormaps() seem relevant. Let's look at it.

Code: Select all

void R_InitColormaps ()
{
	// [RH] Try and convert BOOM colormaps into blending values.
	//		This is a really rough hack, but it's better than
	//		not doing anything with them at all (right?)

	FakeCmap cm;

	R_DeinitColormaps();

...

There's more code after that, but it should be enough. Colormap initialization starts by cleaning up any leftover data. Your custom Powerup.Colormap just got deleted. The powerup, however, keeps thinking it has the 0th colormap for itself.

Long story short, the inverse colormap is then the first re-created and gets index 0 for this reason.

Now you'd say that the obvious solution is to switch stuff around in the main init function so that graphics are initialized before actors... And you could, but it would cause a lot of other bugs for similar reasons in other places in the code. Bugs that are a lot more serious since they pretty much provoke a crash to desktop.


By the way, using Powerup.Color with a color string (e.g. "Yellow" or "#FFFF00") does work and should probably be good enough for what you're trying to achieve here. The reason being that with this property, the actor stores directly a blending color instead of a colormap index.

[Edward-san]

Then Powerup.Colormap is useles, isn't it?

[Gez]

It's a bug. It worked when it was introduced. There should be a way of getting it to work again.

Works in r3244. Broken in r3245.

Up to r3244, colormap init was part of "V_Init: allocate screen." which happens before actors are loaded.

r3244: D_DoomMain() -> V_Init() -> InitPalette() -> AddSpecialColormaps()
r3245: D_DoomMain() -> R_Init() -> R_InitColormaps() -> AddSpecialColormaps()

Reported on the ZDoom forum so closing this as a duplicate. In the meantime, I've fixed it in GZDoom by putting the call to R_InitColormaps() in InitPalette() instead of R_Init().