[won't change]PNGs in FONTDEFS

[AFADoomer]

I'm using the FONTDEFS lump to define a font that's made up of PNGs. The engine automatically converts the image to the palette of the current game when the font is used, though.

Is this by design, or a bug?

Example .wad here (no textures or DECORATE):
http://65.190.169.174/files/doom/example.wad

[Blade Nightflame]

I'm using the FONTDEFS lump to define a font that's made up of PNGs. The engine automatically converts the image to the palette of the current game when the font is used, though.

Is this by design, or a bug?

Example .wad here (no textures or DECORATE):
http://65.190.169.174/files/doom/example.wad

I think you might be missing a HIRESTEX lump in the wad. That's how you can retain the pallete for a graphic. And if you do go with the HIRESTEX lump method, you shouldn't have the font be in TX_START or TX_END markers.

[Graf Zahl]

That is by design. Unfortunately it is unavoidable because it needs the standard palette to perform its internal remappings for the various color ranges. The untranslated range is passed to the texture creating code the same way as any other so the code is unable to recognize it and do something about it. This is all a result from the code's origins. Much of it was never designed to handle True Color and there are a few spots where the only solution would be a fundamental rewrite. This is such a case but a rewrite of this would necessitate to change each text drawing function in the entire game and that's not really worth it.

[Enjay]

Is there any possibility that we could have something added so that we can define colour mappings for fonts. eg, You'll be familiar with my custom palette for "Marine Assault" which alters the blues. In software ZDoom, if I specify blue for a hudmessage it gets shown in my new range of blues but in GZDoom it gets shown in the original Doom blues, not my custom blues - presumably because GZDoom has access to as many colours as it needs for the remapping.

Now, I don't think there should be any change to the default behaviour but being able to take full advantage of all the colours GZDoom can use by defining our own colours (pinks, subtle blues, purples, whatever) would be useful rather than being limited to the 8 or so built in colours.

[Graf Zahl]

If the color tables were trivial to create I'd already have done that. Making the translation table structure dynamic wouldn't be so hard. But exposing this in a way that is flexible enough for customizability is not.

The thing about custom palettes is that you are simply lucky that the software renderer doesn't find any better color matches. If it did your blue translation might become much uglier there.

I changed it to use true color for font mapping for 2 reasons:

1. There is no need to limit the available colors
2. Even Doom's standard font looks much better with certain color ranges and in the other games it is even more noticable - especially Strife which doesn't have most of the primary colors in its palette.

[Enjay]

Absolutely. I agree that they should use true colour mapping (which is why I said the default behaviour should be unaltered). It does look better that way. I also figured I had been lucky with the remapping, although there is very little in the palette likely to have been closer. It's just a shame custom translations are a no-go.

[Graf Zahl]

Just to give you a clue, this is the translation data for the system font:

Code: Select all

		{{ 184.0,  71.0 }, { 184.0,  0.0 }, { 184.0,  0.0 }},	// CR_BRICK
		{{ 204.0,  51.0 }, { 192.0, 43.0 }, { 204.0, 19.0 }},	// CR_TAN
		{{ 200.0,  39.0 }, { 200.0, 39.0 }, { 200.0, 39.0 }},	// CR_GRAY
		{{ 108.0,  11.0 }, { 232.0, 23.0 }, { 104.0,  7.0 }},	// CR_GREEN
		{{ 108.0,  83.0 }, { 104.0, 63.0 }, {  96.0, 47.0 }},	// CR_BROWN
		{{ 140.0, 115.0 }, { 212.0, 43.0 }, { 115.0,  0.0 }},	// CR_GOLD
		{{ 192.0,  63.0 }, {   0.0,  0.0 }, {   0.0,  0.0 }},	// CR_RED
		{{   0.0,   0.0 }, {   0.0,  0.0 }, { 216.0, 39.0 }},	// CR_BLUE
		{{ 223.0,  32.0 }, { 128.0,  0.0 }, {   0.0,  0.0 }},	// CR_ORANGE
		{{ 219.0,  36.0 }, { 219.0, 36.0 }, { 219.0, 36.0 }}	// CR_WHITE

(excluding CR_YELLOW which is done with a separate algorithm.)

and this for the console font:

Code: Select all

	static const struct tp { short mul, add; } transParmLo[CR_UNTRANSLATED][3] =
	{
		{{ 184, 71 }, { 184,  0 }, { 184,  0 }},	// CR_BRICK
		{{ 204, 51 }, { 192, 43 }, { 204, 19 }},	// CR_TAN
		{{ 200, 39 }, { 200, 39 }, { 200, 39 }},	// CR_GRAY
		{{   0,  0 }, { 255,  0 }, {   0,  0 }},	// CR_GREEN
		{{ 255,  0 }, { 128,  0 }, {   0,  0 }},	// CR_BROWN
		{{ 255,  0 }, { 383,  0 }, { 128,  0 }},	// CR_GOLD
		{{ 255,  0 }, {   0,  0 }, {   0,  0 }},	// CR_RED
		{{   0,  0 }, {   0,  0 }, { 255,  0 }},	// CR_BLUE
		{{ 223, 32 }, { 128,  0 }, {   0,  0 }},	// CR_ORANGE
		{{ 255,  0 }, { 255,  0 }, { 255,  0 }},	// CR_WHITE
		{{ 255,  0 }, { 255,  0 }, {   0,  0 }}		// CR_YELLOW
	};
	static const tp transParmHi[CR_UNTRANSLATED][3] =
	{
		{{ 127, 128 }, { 254,   0 }, { 254,   0 }},	// CR_BRICK
		{{ 102, 153 }, { 116, 139 }, { 134, 121 }},	// CR_TAN
		{{ 192,  63 }, { 192,  63 }, { 192,  63 }},	// CR_GRAY
		{{ 254,   0 }, {   0, 255 }, { 254,   0 }},	// CR_GREEN
		{{ 188,  67 }, { 184,  47 }, { 176,  31 }},	// CR_BROWN
		{{   0, 223 }, {  64, 191 }, { 254,   0 }},	// CR_GOLD
		{{   0, 255 }, { 254,   0 }, { 254,   0 }},	// CR_RED
		{{ 191,  64 }, { 191,  64 }, {   0, 255 }},	// CR_BLUE
		{{   0, 255 }, { 127, 127 }, { 254,   0 }},	// CR_ORANGE
		{{ 127, 128 }, { 127, 128 }, { 127, 128 }},	// CR_WHITE
		{{   0, 255 }, {   0, 255 }, { 254,   0 }}	// CR_YELLOW
	};

And now please tell me a decent way to expose this (and explain it in an understandable way.