Most rows of the quake palette tend to gain saturation as they darken. It's an aesthetic choice (a very painterly one) that causes shadows to richen a little bit as the indexes are stepped down by shadows.

Very carefully tuned colored lighting could achieve a similar effect ... 

Software Quake lighting doesn't step down the palette indexes though. It's perfectly possible for a column in the colormap to jump from, say, palette index 89 to 21 as part of a single step in the lighting ramp.

For a real-world example, if we look at column 128 of the colormap, as the lighting darkens we step from palette index 254 to 15 to 14 to 161 to 128; at one point it goes from 4 to 36 to 3 over the space of 3 consecutive steps.

Now, obviously there's nothing in the Quake palette between indexes 4 and 3, so that 36 must have come from taking what it would have been and performing some colour matching to select a palette index to use.

So it's a good deal weirder than just a simple stepping-down of palette indexes. 

I can reproduce the same "painterly" effect in Photoshop in about 10 seconds by overlaying a banal black gradient over the Quake colors, and then quantizing the result into the Quake palette. 

for reference, here is the colormap converted to a PNG:
http://i.imgur.com/BGldFo6.png
(I used lordhavoc's lmp2pcx tool to convert to tga, then gimp to convert that to a png, but had to hardcode the width/height into lmp2pcx because the colormap doesn't have the lmp header) 

The thing is, whether the effect is painterly, or aesthetic, or deliberate, or some, all or none of the above, is totally irrelevant because it's not what software Quake uses for lighting. 

Now it should be noted that when you simply overlay black, the original colors tend to LOSE saturation, not gain it.

Ultimately, the amount of saturation you lose after quantization depends on the palette you quantize to. In Doom, for example, a lot of colors mutate into browns and greys, because the palette sucks for lighting. With a well-balanced palette (like Quake's) it's possible to preserve as much saturation as there was before quantization (but after darkening). Maybe even more in places, but not much more, and only by accident.

Unless you have a very deliberate algorithm for building the colormap, but it's not the case with Quake. 

Software Quake uses colormap. I was talking about reproducing said colormap (its lower part, at least) with a very simple and lazy method. Not sure what you're getting at. 

The lightmap colortable generator seeks the indexed 8-bit color that is closest to the desired 24-bit color for each entry based on least distortion.
distortion = dr*dr + dg*dg + db*db
dr is the red delta, etc.

It runs through the whole palette (minus fullbrights) for each table entry. Slow on a DOS machine, which is why it was generated in advance. ToChris introduced an alphatable to the mix. Engoo embedded the table generation into the engine for colored lighting, fog, and effects. 

but i was wondering if there was some gamma curve in the colormap table that WQ uses.
just to dismiss this idea, I took the 8th color in the first block of browns, plotted the red values from the top of the colormap to the bottom, and it follows a jagged but straight line. 

When clever people talk. 

I should probably point out that at this time, my code cheats and disables mipmaps for those surfaces.
It really only gets away with it because people tend to not run quake at 320*200 any more.
I suspect spirit's regular-gl screenshot used min=linear, mag=nearest, mip=nearest filtering (which is an impossible setting in vanilla glquake).

Its entirely feasable to upload the 4 mips to GL and use only those, but I didn't get around to doing this yet. This would allow it to avoid needless precision loss from mipmapping.
Most gl engines mipmap recursively, accumulating imprecision with every mip, so there's likely benefits to uploading the 4 mips even when not using colourmapping.
Considering this would boost loading times, and reduce imprecision, its a wonder gl engines don't already utilise all 4 mips, yet I don't know of any glquake engine that actually does this - GL_TEXTURE_MAX_LEVEL=3, combined with npot, and us engine devs have NO excuse for shoddy mipmaps.

There'll still be precision differences from the lightmap, and when mipmap boundarys occur. I won't claim that it matches software rendering exactly, but its close enough that you do have to stare quite hard at the walls. 

that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures) 

that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures)

qlumpy source code again; the GrabMip and AveragePixels functions (in quakegrb.c) show that it's just a simple averaging, followed by a nearest colour match, with some error diffusion mixed in at the end for non-fullbright texels.

An obvious risk with user-made textures is that the creator may have never bothered with making miplevels beyond 0. That's something that wouldn't show up in GLQuake and we all know that a lot of content was never even tested in software Quake back in the day (hence stray fullbright texels, bad overbrighting, etc). 

Software Quake lighting doesn't step down the palette indexes though.

Right, it uses the colormap ericw posted, which defines lighting per intensity and palette index as a lookup. And, in almost every case, the values present in that lookup are from the same palette row. That's all I meant.

Either way, shadows gain saturation because the darker values in the palette are more saturated.


Anybody know how Texmex generates mips? Since that's prooobably what everyone's using ... 

>> Either way, shadows gain saturation because the darker values in the palette are more saturated.

Not really.

But sometimes they have different hue (compared to the brighter colors of the same row). 

And, in almost every case, the values present in that lookup are from the same palette row.

Actually in most cases they're not.

Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

The darkest entries in each palette row also each have 64 lighting gradations, and because there's nothing darker in that entry's row the gradations absolutely must come from other rows.

By way of an example, here's a copy of the colormap with the 6th palette row entirely replaced with bright pink: http://imgur.com/5abrpMu

We can see that entries from this row are used in regions of the colormap that correspond to other rows, and we can also see how much of the region of the colormap corresponding to this row actaully comes from elsewhere in the palette.

As ericw has demonstrated above, the colormap is pretty much a straight line as it steps down, which is expected as the code that generates it uses "frac = 1.0 - (float)l/(levels-1);" to calculate the fraction of the base colour for a given light intensity.

What I suspect you're really seeing is that eventually each column in the colormap goes to palette row 0, i.e the greyscale row, so as shadows in software Quake darken they lose their colour too. 

i remember distinctly that the darkest non-black color is a deep red. You see it a lot on the edges of pitch black shadows in software mode. 

>> Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps. 

Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps.

That falls down on two counts.

First of all, each palette row corresponds to (16*64 =) 1024 colormap entries, which would necessitate far too many duplicates.

Secondly, if you actually look at the colormap data itself you'll see that they mostly do come from other rows.

I've posted an example from row 6 above that you can look at and check; over two-thirds of the colormap entries for row 6 come from other rows. The same example can be repeated for every other row if necessary.

I'm not sure what part of this you're not understanding. Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it. We know what we're talking about and we're not talking theoretically. 

>> Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it.

And I actually made a few. And not by running an algorithm.

>> I've posted an example from row 6 above that you can look at and check; over two-thirds of the colormap entries for row 6 come from other rows.

I'm sorry, but you got it backwards. Row 6 is not a "recipient" in your example, it's a "donor".

Note how you painted it pink even in the middle, between the shadow part and the overbright part. The colors are supposed to be "raw" there, they can't come from other rows (unless there's something very wrong).

So yes, the colors are often mixed between rows. But not nearly as much as you think. If you examine pixel columns very closely, you'll see that the colors are often repeated many times. The darker (or brighter) the original color is, the less precision there'll be. 

A minor super8 update is posted that fixes HUD aspect ratio. A config is included for more authentic colors/lighting/hud. This shot from Tronyn's Jam2 entry shows both:
http://super8.qbism.com/wp-content/uploads/2015/02/jam2_tronyn.gif

The config is just:
sbar 2
sbar_show_bg 1
sbar_scale 0.7
r_light_style 0
r_fog 0
r_coloredlights 0
r_palette palette
v_gunkick 0
cl_bobmodel 0
cl_nobob 1 

It's not the colors painted pink that were supposed to come from outside the row, it's all the others.

The example is one of the more extreme ones. A good complementary example would be the red row. It barely has any "foreign intrusions"; the overall amount of unique colors in its part of the colormap is 23, which means a lot of repetition, but it looks very smooth nevertheless.

The point being that using half of the palette to shade one row is unnecessary, and is usually unintended. The reasons for it to happen I can think of:

1. The row in question lacks sufficiently dark and/or bright colors. You still have to shade it somehow, so the only option is to borrow from other rows.

2. The common ways of producing darker and brighter shades tend to mess with hue and saturation. Row 9 is a good example. The brightest colors lose the most saturation when darkened, hence the grey pixels.

3. The math behind quantization may suddenly decide that a color from another row is closer to the shaded color in question than any of the current row's indexes. The grey row is a perfect example.

Quake palette has a lot of similar hues, which means that a lot of colors are interchangeable between rows, so 2 and 3 are rather common. Doom palette has a lot of horrible examples of 1. Many games that I've seen avoid using the colors outside of their rows as much as possible (Strife being a notable example), but that requires less straightforward methods. 

4. When the artists feel especially artsy, they produce rows with inconsistent hue. Row 7 starts with reddish brown and ends with bright yellow. 

It even barfs on red colored lighting like a sw engine:). The lighting looks blended with the textures, especially in dramatic contrast areas. In GL the lighting can look airbrushed or too smooth when the lightmap ramp is steep. sw engines can run into banding here but it can be solved with dithering. Which in normal conversation seems ironic. 

It cheats when it comes to coloured lighting. It still has a 24bit colour framebuffer, so it just does 3 colourmap lookups instead of 1. This can result in different colour channels banding at different points.

The actual glsl code is here:
the EIGHTBIT define is true for colourmapped surfaces.
http://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/engine/shaders/glsl/defaultwall.glsl

once you already have glsl in your engine, its actually pretty trivial to do this. just the 8bit texture loading, colormap loading (no header!), and glsl tweaks.
This would actually have been possible even without any engine changes, but would have needed lots of external textures+shaders.