Question about Dos Doom rendering and the VGA

So, as I understand it, the VGA has a mode called 13h, 320 x 200 x 1, 256 colors, and doom's renderer uses this mode. I'm wondering how doom implements sector lighting in this mode. If the color palette is 256 colors, and the colormap lump is used to remap colors for lighting, wouldn't a varied scene light-wise result in more than 256 colors? Is doom using a special mode on the VGA, or does doom handle the extra colors in a special way?

Here's an image of Doom's COLORMAP, as per the Doom wiki. I would rotate it but I'm lazy :p



The image is 256 x 34 pixels (512 x 68 here, it's been doubled for easier visibility). The leftmost column is every colour in the Doom palette. The next 31 columns are the colours dimming through progressively darker lighting. Note that the image is just a 256 colour image, made from the 256 colours of the first column! So you don't get smooth transitions, but clear blocks and bands of colour. Some colours are better than others; greys and greens are great, but purple is awful.

You seem to have misinterpreted how the colormap works. It doesn't add/change colour, it remaps them to each index in the palette. This also means there's a limited range in how lighting can affect a colour under the same 8bit palette. The same wiki page will show you this effect.

So no, there's not more than 256 colours for sector lighting.

Edit: Well that was quick. Beaten by plums.

The colormap only uses the existing 256 colors. For each color in the palette, it treats that color as being fullbright, and then darkens it in increments of 1/32 towards black, picking the nearest color in the existing palette.

edit: damn beaten twice

Thanks guys, I was reading tricks of the game programming gurus and it mentions palette swapping. I guess the color map being 256 colors explains why the reds turn brown as it gets darker.

Omg, this colormap is awful! I don't get a point, why did they made it look like this. Is there a way to give reds their normal range?

That would require a different colour curve (which would only change the accuracy of the reds), or more colours (16bit back in 1993 was non-standard and horrifically slow), or sacrificing other colours for more reds.

I wonder if that would have worked any better if they had used a RGB332 color palette.

ABRACADABRA said:

Omg, this colormap is awful! I don't get a point, why did they made it look like this. Is there a way to give reds their normal range?

As said before, the colormap is limited to using the 256 colors in the base palette. The software which generated this colormap translated every "perfect" shaded color into its closest approximation from the palette, and didn't take into account which range was it from. That said, colormap can be generated in any way you want, you can even draw it in an image editor by hand, then put it into a wad and it will override the default colormap. Similarly, it's possible to make/edit and replace the palette itself.

Sigvatr's PALPLUS:
https://www.doomworld.com/idgames/graphics/pal_plus

Or you can try the Technicolor pallette or the pallette from Spork's Simplicity ...

Don't forget that Doom originally was to have a 15-bit, 32K color mode, which could display (in theory) all colormaps at once, if the conditions were right.

Only that due to unknown (but easily imaginable) technical reasons, it never made it to the finished DOS product, except as a vestigial implementation in the v0.4 Alpha. It's unknown whether it ever had a full implementation on the NeXT development version, though it appears probable, since there was even a 12-bit 4096 color mode (4-bpc ARGB).

FWIW, both the 32K and 4K color modes had problems of their own: yeah, they could display more than 256 colors at once, but the quantization per color channel was so bad (esp. on the 12-bit one) that the darker colormaps looked like crap anyway, banding was still visible, and in many cases looked worse than the 256-color remapped mode we all got to know. Here's a simulation of what the 4K color mode looked like.

Only ports with RGB565 or True Colour displays with extended colormap support really make a worthwhile visual difference, so the 256-color mode is actually pretty good for what it is.

It is of course possible to alter the base PLAYPAL as well as the COLORMAP to produce interesting results or subjectively better visuals. The method used to originally create the COLOMAP from the PLAYPAL in dcolors.c was just a straightforward nearest-neighbor color matching, not taking into account any psycho-visual, aesthetic or perceptual cues.

ABRACADABRA said:

Omg, this colormap is awful! I don't get a point, why did they made it look like this. Is there a way to give reds their normal range?

I remember reading in the thread for the palplus mod that the original palette was calibrated for the quirks of common computer monitors at the time.

Sometimes I play with PALPLUS and it looks pretty damn nice. It's just a shame that there are often compatibility issues with wads that add new content. You could probably use post-processing overlays instead like ReShade/SweetFX to get similar color changes.

did a quick photoshop run over some colors. still looks like ugly mess, but I'll keep trying

Lemme pull a Maes here and do some selfquoting

Linguica said:

SLADE makes it pretty easy to generate colormaps using other algorithms, and IMO none work as well as the simplistic method Carmack used.


The normal RGB method Carmack used.


HSL.


CIE 76.


CIE 94.


CIEDE 2000.

Here's another manually tuned colormap:

Linguica said:

jmickle66666666666666 shared with me a manually edited colormap he had made a while back where he defined color ramps. It was interesting (it avoided the desaturation problem) but went a little overboard in the opposite direction, e.g., demons and barons turned CRAZY BLOOD RED in low light.

And an algorithmically generated one I made that tries to retain more color saturation:

Linguica said:

Here's one with the saturation bump half as strong:

Can you put them in wad format so they can be used directly?

sudo459 said:

Thanks guys, I was reading tricks of the game programming gurus and it mentions palette swapping. I guess the color map being 256 colors explains why the reds turn brown as it gets darker.

Palette swapping is a different trick to COLORMAP; Doom uses palette swapping to implement the "red screen" / "flash of yellow" effects when taking damage / picking up items (also for the rad suit's green tint).

Isn't that slow to do in realtime? Of course I mean for computers of the day. Its like 4 writes per color and 256 colors. Is there a trick that doom used?

There's also a VGA BIOS interrupt that allows you to set the entire 256-color palette at once, though I have no idea how it compares performance-wise to just manually writing 256*3 bytes (plus one more to select the initial palette index).

Linux Doom basically takes the manual approach (albeit using X11 calls instead of dealing with VGA registers due to running in a windowed environment).

Abrash discusses how to change the palette in his black book: http://www.jagregory.com/abrash-black-book/#chapter-34-changing-colors-without-writing-pixels

sudo459 said:

Isn't that slow to do in realtime? Of course I mean for computers of the day. Its like 4 writes per color and 256 colors. Is there a trick that doom used?

The amount of data used to fully redefine a 24-bit RGB palette is 768 bytes, exactly the size of each of the PLAYPAL lump's palettes. Compare it with the amount of data required to refresh the entire VGA buffer 35 times per second at vanilla resolution.: 2.24 MB/sec. For reference, the ISA bus was clocked at 8 MHz, whether 8- or 16-bit.

That being said, palette changes WERE noticeably slower than screen refreshes. You couldn't write the data and go on your merry way, you had to wait for the VGA card to respond, acknowledge and apply the change, and some were notoriously worse than others.

The real bottleneck, as the text Linguica linked to, was that the port OUT operations were painstakingly slow anyway, even on Pentiums, and not suited to this sort of real-time manipulation. This is more of an architectural limitation of the IBM PC - Compatible architecture, which we're still using to this day, a fixed overhead that hasn't and won't go away.

That being said, for an effect that was used in less than 1% of the rendered frames during an average Doom game, there hardly was motivation (or technical possibility) to do something better. The effect only becomes computationally "expensive" if you try replicating it with a non-indexed display (HiColor or TrueColor), without using trickery like hardware overlays/tinting.

sudo459 said:

Isn't that slow to do in realtime? Of course I mean for computers of the day. Its like 4 writes per color and 256 colors. Is there a trick that doom used?

Nope, one of the main reasons palette shifting was so popular back in the day is that it's quicker to change the palette than to update the whole screen.

LogicDeLuxe said:

I wonder if that would have worked any better if they had used a RGB332 color palette.

I experimented with this, once, making a RGB332 palette and colormap, then converting all the graphical assets to PNG and loading up ZDoom to see the results.

The answer is you get some very questionable ramps. Grays, for instance; because the blue channel has less information than the other two, you're basically stuck wobbling between slightly blue and slightly yellow for the entire gray ramp.

A different approach I tried was 6 shades of red, 8 shades of green, 5 shades of blue, and 16 intermediate gray shades (#000000 and #FFFFFF were handled already) to round out the resulting 240-color palette to 256 entries. This fixes the problem with the gray ramp, but then you run into the other problem the RGB332 palette had - the steps towards black are a lot larger, so the banding looks considerably worse than it did to begin with. You do gain a wider color palette to work with, at least, but it's gonna look bad as it fades toward the distance.

Now granted, this might look better if you were using art assets designed for the palette in question instead of Doom assets in truecolor PNG being converted to the nearest palette entries first by ZDoom and then thrust into the COLORMAP shenanigans from there... although I'm not entirely sure it would.

In the end, Doom's 256 color palette with an effective 18-bit color depth (6 bits per channel) was better than any of the other technically viable alternatives, including the elusive 32K color mode, and despite its weaknesses, was a simple and elegant solution. ALL HAIL THE One True Doom palette!