All palette values which are "significant" codeside?

[ETTiNGRiNDER]

Which palette entries have special meaning to Doom, if I'm making a custom palette?

The color translation ranges were easy enough to look up on ZDoom wiki:
0 turns green into grey (112:127=96:111)
1 turns green into brown (112:127=64:79)
2 turns green into red (112:127=32:47)

But what about automap colors and anything else that might be hard coded?

[scifista42]

-Index 0 should be pitch black, I think that I've encountered some glitches when I once made a palette that started with white.

-Index 255 might display as black in some source ports, because it's hardcoded for alpha trancparency or something. In other source ports, this gimmick applies about index 247 instead! At least I think so.

-Automap colours are customizable in source ports, check config file of a specific source port to see the default values, if you're concerned about automap colours of your own custom palette in that source port.

[jmickle66666666]

no colours are hardcoded transparency. color 255 was used internally at id for the graphics but the engine doesn't care. it's not used in the graphics but it can be. It's used in the colormap. The magenta color 251 is also not used in any graphics, but is used in the colormap (but only for itself and color 250, which is very very rarely used). Tool makers assumed this was a transparent color so a lot of old tools rely on this. Nowadays it isn't an issue.

As far as I can tell from my experiments, you can do anything with the palette and it's fine. I've used color 0 as non-black and not had issues with zdoom, but not tried with other ports. With pr-boom+, I have found no adverse effects of changing any other color at all.

[Linguica]

Here's the coloration stuff for the automap. The numbers are palette entries.

#define REDS		(256-5*16)
#define REDRANGE	16
#define BLUES		(256-4*16+8)
#define BLUERANGE	8
#define GREENS		(7*16)
#define GREENRANGE	16
#define GRAYS		(6*16)
#define GRAYSRANGE	16
#define BROWNS		(4*16)
#define BROWNRANGE	16
#define YELLOWS		(256-32+7)
#define YELLOWRANGE	1
#define BLACK		0
#define WHITE		(256-47)

// Automap colors
#define BACKGROUND	BLACK
#define YOURCOLORS	WHITE
#define YOURRANGE	0
#define WALLCOLORS	REDS
#define WALLRANGE	REDRANGE
#define TSWALLCOLORS	GRAYS
#define TSWALLRANGE	GRAYSRANGE
#define FDWALLCOLORS	BROWNS
#define FDWALLRANGE	BROWNRANGE
#define CDWALLCOLORS	YELLOWS
#define CDWALLRANGE	YELLOWRANGE
#define THINGCOLORS	GREENS
#define THINGRANGE	GREENRANGE
#define SECRETWALLCOLORS WALLCOLORS
#define SECRETWALLRANGE WALLRANGE
#define GRIDCOLORS	(GRAYS + GRAYSRANGE/2)
#define GRIDRANGE	0
#define XHAIRCOLORS	GRAYS

So I would suppose that the background is 0, the player is 209 (which is NOT white...), normal lines are 176, floor height changes are 64, ceiling height changes are 231, other lines in IDDT mode are 96. Also W1 teleport lines but not WR (??) are 184.



It would be pretty evil to make a WAD with a custom palette that changed the automap wall colors to black or something.

[Mechadon]

PrBoom+ use to have an issue with Index 255, though this may have been changed at some point. See this thread. I ran into this issue with Supplice's modified palette. As you can tell, one of the yellow colors that we had in index 255 wouldn't display properly in PrBoom+, but there were no issue in ZDoom, EE, or WinMBF.

[jmickle66666666]

weird!

[myk]

jmickle66666666 said:
no colours are hardcoded transparency. color 255 was used internally at id for the graphics but the engine doesn't care. it's not used in the graphics but it can be. It's used in the colormap.

Not really. It's a valid color, is used by a few graphics in the IWADs, and what you describe is something the tools that import graphics do and that pallet color is also used for the frame rate dots that appear at the lower left corner of the screen in developer's mode (in the original and any port that sustains that part of the code).

[jmickle66666666]

i meant to say "used internally at id for transparency" whoops :/

[myk]

But, now that I double-checked, you were right in terms of usage in the id graphics. I knew this had been discussed before, and some thread in the past had listed the colors not used in each IWAD (in the DOOM games and the Raven games), and 251 and 255 don't appear in the DOOM game graphics.

[kb1]

Some interesting facts about palette usage in Doom2:

Most used color: 78 (in 215,537 pixels)
2nd most used: 79 (in 211,643 pixels)
Not used: 251 and 255 (already stated)
Least used: 252 (in 13 pixels)

Black usage:
0 - by far the most (163,496 pixels)
247 - (4,632 pixels)

White usage:
4 - by far the most (25,402 pixels, in 294 patches and 1 flat)
224 - (1,670 pixels, all in patches)
168 - (276 pixels, all in patches)
208 - (190 pixels, all in patches)

These colors are not used in flats at all:
17, 112-117, 168, 192-197, 208-220, 222-224,
232-234, 246, 248-255

Color 219 is used in 259 patches, but no flat.
Color 234 is used in 9,943 pixels in patches, but no flat.

Color 76 is used in the most patches (1,368).
Color 78 is used in the most flats (68).

[jmickle66666666]

here is the post where I explained my findings about the doom palette:

http://www.doomworld.com/vb/post/1343648

[Gez]

myk said:

But, now that I double-checked, you were right in terms of usage in the id graphics. I knew this had been discussed before, and some thread in the past had listed the colors not used in each IWAD (in the DOOM games and the Raven games), and 251 and 255 don't appear in the DOOM game graphics.

There are two pixels in the Doom II city sky that are transparent because, I presume, the closest matching color for them was color 255.
http://www.doomworld.com/vb/post/1014176

[myk]

Yeah, makes sense, and it explains some other transparent holes in sprites such as the arachnotron and I think maybe the zombieguy. When the graphics were inserted, any and all color 255 pixels within the artwork got eliminated accidentally by the fact that it was the "background" color for the editing tools id used.