[MAPINFO] level specific palletes.

[Gez]

I really just program in Python, but I am looking at the source code now, and if someone could point me at the relevant sections it would save me some time. I may not be able to do anything useful, but I am willing to try and help.

Well, if you're not familiar with C++ it might be a bit hard to puzzle out how it all works; but for reference, what you want is void InitPalette () in v_palette.cpp.

The relevant parts, for the typical Doom game (the rest is [wiki]Build[/wiki] support code which are generally not used), are this:

Code: Select all

	FWadLump palump = Wads.OpenLumpName ("PLAYPAL");
	palump.Read (pal, 768);
	GPalette.SetPalette (pal);
	GPalette.MakeGoodRemap ();
	ColorMatcher.SetPalette ((DWORD *)GPalette.BaseColors);

	// Colormaps have to be initialized before actors are loaded,
	// otherwise Powerup.Colormap will not work.
	R_InitColormaps ();

As you can see, there are a few reasons why you can't just recall InitPalette() in between levels, however. A R_ReInitColormaps() function would have to be created first.

[albiongeck]

Just a quick update rather than proof of viable code: I've been away for a while now, but I did get code working to change the palette to any of the other original Doom palettes, and refresh the screen. Rather than just loading the first 768 bytes of PLAYPAL, the whole thing is now loaded and is accessed in multiples of 768 bytes by a console command (sorry for the stupid name) "initpalette n". Refresh then basically reuses the change resolution code without actually changing anything.

This would appear to be enough if people are willing to tailor their palettes to the doom colour map, and shouldn't be hard to tie to ZMAPINFO. There are bugs with fullscreen modes but I will address these once I've got colormaps working (below). The palette changes DO bleed through into powerups (whiteout effect of invulnerability particularly), which I would say is expected behaviour, but possibly undesirable.

I am now working on replacing the loaded original Doom colormap levels (according to the ZDoom wiki, levels 0-31 are still used) with a colormap that is generated from the palette itself, using bestcolor() to pick the closest available shade. Could somebody tell me about the way colormap levels 0-31 are loaded, as trying to follow this in the code was a bit of a headache for me last time I tried.

[albiongeck]

I believe I have the colormap issue solved now, a complete 32 level colormap is generated from the palette itself at runtime, resulting in much better behaviour for custom palettes. Now I need to integrate this into the palette swap function and tidy up the bugs. This videos uses a palette not intended for Doom (so the colours are wrong) which highlights the problems with using the static colormap from the wad (default behaviour).

[Gez]

That's interesting.

When you say they're generated at runtime, how long does it typically take? It'd be interesting if, in addition to changing the colormaps in between levels, there could be some console command (for testing) and ACS function allowing to change the palette (and rebuild the colormaps) while playing. Could allow some really interesting effects. (Among others, allow to use genuine [wiki]palette flashes[/wiki] instead of emulating them with blending, without sacrificing truecolor support).

[randi]

(Among others, allow to use genuine [wiki]palette flashes[/wiki] instead of emulating them with blending, without sacrificing truecolor support).

Considering that GZDoom would have to regenerate every texture after changing the palette, using them for flashes doesn't sound very viable to me. (And isn't generally useful anyway.)

[Graf Zahl]

Not only that, but how should that even work with textures that aren't limited to the Doom palette?

This would be a feature that'd obviously be limited to a paletted renderer, and if I remember correctly for the same reason Boom's TRANMAPs were nixed.

[NeuralStunner]

Doesn't ZDoom generate colormaps for fogged sectors?

The other issue with dynamic colormaps is losing support for fullbright colors (like Strife and Harmony have). One of my favorite effects in the engine, really. I think it would make sense to only generate a colormap if one isn't specified.

It'd be interesting if, in addition to changing the colormaps in between levels, there could be some console command (for testing) and ACS function allowing to change the palette (and rebuild the colormaps) while playing. Could allow some really interesting effects.

Or 8-bit color cycling.

[Gez]

Since a truecolor renderer is truecolor, it can keep using blending effects without color deterioration.

As for fullbright colors, it's possible to detect them (that's what GZDoom does to create brightmaps automatically), so they can be flagged as remaining full-bright while the dynamic colormaps are generated.

[Graf Zahl]

Since a truecolor renderer is truecolor, it can keep using blending effects without color deterioration.

Not if the palette is abused to handle them. I strongly suggest to forget the idea to switch palettes during the level at runtime as quickly as possible. This is something that's never ever going to work with a renderer that can't make use of palettes and has to convert the images to truecolor.

With older versions of GZDoom that didn't cache palette translations this even caused problems just for a small number of sprites if they had to be constantly recreated. So things like color cycling or transitional effects are out of the question if you don't want to deadlock the engine to 8 bit rendering.

[NeuralStunner]

As for fullbright colors, it's possible to detect them (that's what GZDoom does to create brightmaps automatically), so they can be flagged as remaining full-bright while the dynamic colormaps are generated.

Only if those colors remain in the same place for each palette, which would be smart on the modder's part but can't be assumed.

I strongly suggest to forget the idea to switch palettes during the level at runtime as quickly as possible. This is something that's never ever going to work with a renderer that can't make use of palettes and has to convert the images to truecolor.

Since ZDoom typically ignores GL-only features, could GZDoom ignore this effect? I'm unsure how extensive Software -> GL compatibility is.

[Graf Zahl]

ZDoom never added Boom's TRANMAP for the exact same reason - it'd lock the renderer to 8 bit output.

I don't see it happen here, just because you happen to think it's a cool idea. It still is a crippling feature and would block a proper implementation of a true color software renderer.
Sometimes features have to be rejected just to prevent mappers from doing stuff they shouldn't even think of. Just because some things are technically possible doesn't mean they should be done.

[NeuralStunner]

Heh, I tend to forget that one of ZDoom's possible futures is a 32-bit software renderer. Yeah, in that case it sounds like a thing to avoid.

[albiongeck]

Okay, good to see people scrutinising the ideas here, which is always a good thing to prevent wasted time and knots of legacy code. There are some points I agree with, but others I don't really see yet.

In chronological order:

how long does it typically take?

It doesn't seem to add any visible overhead at this point, but I can't say beyond that. This is a moderately fast laptop and I have no data yet how it scales with hardware.

Considering that GZDoom would have to regenerate every texture after changing the palette, using them for flashes doesn't sound very viable to me. (And isn't generally useful anyway.)

This is purely intended to be ZDoom (non openGL) code, to overcome a single limitation of the 8 bit renderer, the same way that other engines historically have, by setting the palette once per area (not during the level).

Doesn't ZDoom generate colormaps for fogged sectors?

Could you link me a wad with fog so I can test this behaviour?

The other issue with dynamic colormaps is losing support for fullbright colors

I had not even thought of this yet, if this is implemented I it guess could be fixed with extra ZMAPINFO flags or similar, it depends how much extra code is tolerable.

I think it would make sense to only generate a colormap if one isn't specified.

Agreed. If a colormap is available there's no way we could get more authenticity than that anyway. The code I've written could also be adapted to test if any present colormap would be sane for the palette before generating a new one.

ZDoom never added Boom's TRANMAP for the exact same reason - it'd lock the renderer to 8 bit output.
...
It still is a crippling feature and would block a proper implementation of a true color software renderer.
Sometimes features have to be rejected just to prevent mappers from doing stuff they shouldn't even think of.

Could you explain this to me in more detail (either here or by PM is fine) as I really don't think I understand it myself. If ZDoom moved to 32 bit renderer, all the code for a palette switch workaround could be eliminated. (On a side note, a glance at the forum seems to suggest that a 32 bit solution would probably opt to ditch a lot of code anyway).

I'm sorry if I misunderstand badly, but I would guess that in 32 bit, the plan for current content is:

Doom GFX -> default palette -> decode to 32 bit graphic for use in renderer

whereas the flow with legacy content would be

check at wad loading if multiple palettes are used -> if yes, retrieve palette number at level loading
Doom GFX -> MAPINFO chosen palette slice -> decode to 32 bit...

which doesn't seem like much legacy code to get stuck with in the long run.

In any case, if 32 bit rendering were here tomorrow, I would agree that it is best to forget this idea - but do we have any progress in this area? I think whether to continue trying to implement a workaround should be decided by how long this need is likely to exist for.

Apologies for the long post, any misunderstandings and especially any misquoting.

[randi]

Mine and Graf's concerns with Gez's idea to abuse this for doing palette flashes. There's nothing wrong with being able to switch the palette for different levels or sections of levels.

[TheDarkArchon]

Given you can already eye rape people with texture switching, fog switching and light switching, it's pretty much a non-issue.