Some things assume palette index #0 is black

[Xane123]

Not sure how else to word it, but some things in GZDoom (even in very old builds) assume palette index #0 will always be black. For example, I've seen in the source code in the past that some parts of the source code call "Clear" with a palette index of 0 when there's "GPalette.BlackIndex" which would choose the correct color.

My game uses a palette where a light pink is palette index #0, the first color, while black is near the end of it. The results are quite ugly. For example, the save/load menu:

The save/load menu uses this a lot.

In this case, back in March 2016, the old build I was using, though the picture above is of the latest git version, stuff like this was in the source code:

Code: Select all

// Draw comment area
	V_DrawFrame (commentLeft, commentTop, commentWidth, commentHeight);
	screen->Clear (commentLeft, commentTop, commentRight, comment Bottom, 0, 0);
	if (SaveComment != NULL)
	{
		// I'm not sure why SaveComment would go NULL in this loop, but I got
		// a crash report where it was NULL when i reached 1, so now I check
		// for that.
		for (i = 0; SaveComment != NULL && SaveComment[i].Width >= 0 && i < 6; ++i)
		{
			screen->DrawText (SmallFont, CR_GOLD, commentLeft, commentTop
				+ SmallFont->GetHeight()*i*CleanYfac, SaveComment[i].Text,
				DTA_CleanNoMove, true, TAG_DONE);
		}
	}

	// Draw file area
	V_DrawFrame (listboxLeft, listboxTop, listboxWidth, listboxHeight);
	screen->Clear (listboxLeft, listboxTop, listboxRight, listboxBottom, 0, 0);

The console, while not as ugly, has a similar pink line at its bottom.

The console's pink line.

To see this problem, use this WAD file, which replaces PLAYPAL.

palette_problem.wad

Test WAD which includes my game's palette.

(796 Bytes) Downloaded 20 times

I've fixed this in the source before but I'm not sure what's responsible for the save/load menu's big pink areas now that code is both in the source and in the ZScript folder. I've seen the wrong color chosen in other areas like D_PageDrawer. The only way to fix this would be to look through the source code and correct every "Screen->Clear(#,#,#,#,0,0)" and change the second-to-last zero to GPalette.BlackIndex.

[Graf Zahl]

Internally, index #0 is used for transparency. You are strongly advised not to put any relevant color there at all as it will show discrepancies between software and hardware renderer in a few cases where the palette is being used directly.

[Xane123]

Oh, I don't know if I read that when making the palette, but I think I heard ZDoom automatically chooses a color that appears twice in the palette as transparency otherwise. I included the pink at the end of the palette as well, which mean so ZDoom chooses it as transparency.

This isn't the cause of those things being pink, though. They don't choose the right thing, GPalette.BlackIndex, instead using 0 like the first color will always be black.

[Rachael]

Here's the big issue: Color #0 is always assumed to be black, regardless, and it's not by accident.

It's been that way since the first Hercules graphics card, to CGA, to EGA, and even to the default VGA palette values. And with almost all of these adapters, changing attribute 0 to represent any color other than black would cause a border to appear out of the graphics drawing bounds. (It was a neat trick, but ultimately very underused, and few if any emulators actually emulate it - some games did take advantage of it, though)

Basically, the long and short of it is this: Unless you have some compelling reason to set 0 to a non-black value, it really comes down to "don't do that!"

I think at this point it comes down to a decision whether to keep that behavior for the intent of extra customizability, or to painstakingly go through the source and replace every instance of "0" (hard to find since it's used a lot outside of colors) with GPalette.BlackIndex

[Xane123]

Ah, I understand. I'm not sure how I'd make a pull request or where to post it, but while I could change the "0"'s into GPalette.BlackIndex, some of the problems are in the ZScript files and I don't know what ZScript's counterpart to GPalette.BlackIndex is. For example, the save/load screen (/wadsrc/zscript/menu/loadsavemenu.txt):

Code: Select all

		Screen.DrawFrame (savepicLeft, savepicTop, savepicWidth, savepicHeight);
		if (!manager.DrawSavePic(savepicLeft, savepicTop, savepicWidth, savepicHeight))
		{
			screen.Clear (savepicLeft, savepicTop, savepicLeft+savepicWidth, savepicTop+savepicHeight, 0, 0);

			if (manager.SavegameCount() > 0)
			{
				String text = (Selected == -1 || !manager.GetSavegame(Selected).bOldVersion)? Stringtable.Localize("$MNU_NOPICTURE") : Stringtable.Localize("$MNU_DIFFVERSION");
				int textlen = ConFont.StringWidth(text) * CleanXfac;

				screen.DrawText (ConFont, Font.CR_GOLD, savepicLeft+(savepicWidth-textlen)/2,
					savepicTop+(savepicHeight-rowHeight)/2, text, DTA_CleanNoMove, true);
			}
		}

		// Draw comment area
		Screen.DrawFrame (commentLeft, commentTop, commentWidth, commentHeight);
		screen.Clear (commentLeft, commentTop, commentRight, commentBottom, 0, 0);

		manager.DrawSaveComment(ConFont, Font.CR_GOLD, commentLeft, commentTop, CleanYfac);

		// Draw file area
		Screen.DrawFrame (listboxLeft, listboxTop, listboxWidth, listboxHeight);
		screen.Clear (listboxLeft, listboxTop, listboxRight, listboxBottom, 0, 0);

		if (manager.SavegameCount() == 0)
		{
			String text = Stringtable.Localize("$MNU_NOFILES");
			int textlen = ConFont.StringWidth(text) * CleanXfac;

			screen.DrawText (ConFont, Font.CR_GOLD, listboxLeft+(listboxWidth-textlen)/2, listboxTop+(listboxHeight-rowHeight)/2, text, DTA_CleanNoMove, true);
			return;
		}

There's a couple clears with palette index #0 in there!