Don't have bug:
WinQuake
Quakeworld (any GLQuakeWorld, FTEQW, ezQuake, ...)
DarkPlaces
DirectQ + Remake Quake (pretty sure)
Mark V
Modern ProQuake (although I've seen a bug)

It is a pain to address because to do it right, you have to keep track of the color map for all entities (scoreboard) and then if a player color changes you have to recolor any skin or texture (it might not be player.mdl -- the player could have been gibbed. Some mods support more than 1 skin. Some mods support more than 1 model.). Then you have the problem that if the engine supports external 24-bit textures, then how do you even know what parts of the image are shirt or pants color (so DarkPlaces, for example, has _shirt and _pants support. ezQuake has something similar).

WinQuake doesn't care, it is a palette based renderer so when it paints color it can seamlessly substitute a slightly different palette -- it doesn't need to repaint a texture.

Stock Quakeworld including ezQuake just do it for the player skin. FTEQW from what I recall Spike saying, does it correctly for everything.

It isn't easy to address in code, you have to check changes in entities and changes in the player color too and rework the texture manager. It isn't fun. 

If a player does not change their color or model, could the corpse then still use the live player's already recolored texture in memory? Players changing models or colors is so rare that it would be a lot less jarring to revert when that happens than always upon respawning 

even when you do it 'properly' you still have weirdness when people disconnect or change teams (TF spies... grr, or worse: TF's animated+coloured teleport pads). 

could the corpse then still use the live player's already recolored texture in memory

You still have to keep track of what corpses go with what player. What if a player disconnects? What if a player grabs an invisibility ring? And if you ignore those, you still have to actively monitor any entity to be a corpse and change stuff in the texture manager. And there can be models with invalid skin numbers.

Doing it poorly isn't much easier than doing it right. Even doing it poorly is hard.

There aren't any easy answers for this one, but one of the older Mark V source codes has the changes marked in a straightforward manner. 

i've found that assigning a corpse's colormap to the player to work.

if ((gl_color_deadbodies.value) && (ent->model->modhint == MOD_PLAYER))
{
if (ent->colormap > 0)
{
texture = (playertextures) + ((ent->colormap - 1));//Colored Dead Bodies
fb_texture = fb_skins[(ent->colormap - 1)];
}
else
{
texture = (playertextures);
fb_texture = fb_skins[0];
}

Though, i'm getting black skins when someone is culled via cullentities...but the corpse suddenly 'color corrects' itself when the owner of the corpse comes into view.

And for 24bit skins i use ent->pantscolor ent->shirtcolor and run a pass twice over the model for shirt and pants; which DOESNT have any issues at all. 

edit:

in world.qc in the bodyque
we already have
bodyque_head.colormap = ent.colormap;

so we are already 'tracking' the color of the owner in quakec. 

here's how im assigning the shirt & pants in cl_parse

if ((i > 0 && i <= cl.maxclients) && (ent->model) && (ent->model->modhint == MOD_PLAYER))
{
ent->shirtcolor = (cl.scores[i - 1].colors & 0xf0) >> 4;
ent->pantscolor = (cl.scores[i - 1].colors & 15);
ent->colormap = i;
} 

I have linked an image comparison of three views of jam5_hypnos.bsp.

http://i.imgur.com/WIAAvmL.png

It shows how the fog looks in Darkplaces versus Quakespasm 0.90. You will see that if I look across the grimy water in QS the fog colors all of its surface light blue even near me. However, if I walk right to the edge and look down, the liquid texture appears in place of the fog color. In other words, the direction I am looking affects how the liquid surface looks, which is weird.

I'm not sure what is going on here. Could I be using some odd fog setting accidentally that makes it work this way? Does anyone else see this, or does it look more like the Darkplaces screenshot to you in Quakespasm too? 

The rendering effect I described above happens when I have r_oldwater set to 0. If I enter r_oldwater 1 in the console, the scene looks similar to the DP screenshot.

So if you try to reproduce, see if the two different r_oldwater settings have the same effect for you. 

Hmm, thanks for the report. At first glance I can't reproduce that, with QS 0.90.0 r_oldwater 0/1 look the same (except the slight difference in water quality). Here's r_oldwater 0:
https://www.dropbox.com/s/z4n1kibgu13qr2i/primal1.jpg?dl=0

I have a guess at what's happening from you screenshot - with "r_oldwater 0" the water texture gets drawn on the screen between frames and copied back to a texture, it looks like it's picking up the fog there.

Would you mind checking whether you get the same issue with fitzquake 085? http://www.celephais.net/fitzquake/

Also, what's your graphics card? 

I ran fitzquake with Wine and got the same result when I set r_oldwater to 0 in the console. Same thing with the water texture coming out when looking downwards too.

I have 64-bit Ubuntu on my laptop with an integrated gfx card. Here are some lines from my glxinfo.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30 

There are like 3 or 4 different fog implementations in engines and that sucks. 

Here is a little bit of video that shows how looking down changes the appearance of the slime.

I'd like to add that I can simply set r_oldwater to 1 and not worry about this glitch at all. So please don't spend too much time on this as long as it is just my system which has this problem.

http://i.imgur.com/7EhYPvi.gifv

(I should know by now how to record windows without including the header bit, but I forgot to do it right again while making this one. Derp.) 

I will have a look, I should be able to fire up ubuntu on a Haswell laptop. 

happens for me too, Ubuntu 14.10,
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.0 Mesa 10.3.0

Will poke around a bit more 

The problem seems to be mesa is choosing to use vertex fog, which it is allowed to do in OpenGL. I tried adding glHint(GL_FOG_HINT, GL_NICEST) but still get vertex fog.

The other half of the problem is, there's a water textured func_illusionary stretching across the whole map; water doesn't get cut up by qbsp, so there are two giant triangles. Since the corners of the triangles are so far away they get fogged to solid white. You can see the issue if you do r_drawworld 0, r_oldwater 0, r_showtris 1, and noclip up above the map. "r_oldwater 1" avoids the issue because it chops up the water surface into smaller triangles that look ok with vertex fog.

So there's not much we can really do... I was thinking of upgrading the fitzquake "r_oldwater 0" effect to glsl at some point, and that would fix the problem since we can force per-pixel fog in the shader. 

Thanks for looking at this, EricW. 

http://texelstorm.tumblr.com/post/106248773719/anyone-with-access-to-an-oculus-development-kit 

cause I posted it on my quakeguy blog ;) 

So, i just downloaded Quakespasm source and i'm curious about the software renderer. Has it been removed? Is it possible to compile the engine without GL? 

QS is OpenGL only, which dates back to Fitzquake.

Check out Fitzquake Mark V which re-adds the software renderer to Fitzquake. 

@ericw ... when you modified how the map is drawn by removing DrawSequentialPoly, did you discover any side-effects? And did you fix them?

I recall someone saying something about alpha or sorting --- perhaps alpha entities or water in some odd situations could be wrong. 

I don't think there were any issues with the final version of the patch.. the overall draw order is the same as before (opaque entities, world water, transparent entities). Only real difference is, within a particular entity, instead of drawing the faces in the order from the bsp file, they're now sorted by texture.

Maybe it was mh or metlslime pointing out that fitz doesn't depth-sort all of the alpha surfaces. So in your example, fitz and qs should always draw transparent entities on top of water.. this will look wrong if you have a transparent window underwater, viewed from above. MH's engines do sort every transparent surface properly, I looked at that but it's a bit of work to set up.

I do have a test map for checking weird cases like water textured bmodels, fullbrights on transparent bmodels, alpha bmodels in water, etc. Was meaning to upload it but forgot about it. I'll dig it out and upload it tomorrow. 

Yeah, it's quite a bit of work to sort all the alpha surfaces properly and even more if you want to add sorting for other stuff like alpha MDLs, sprites, particles, etc. Particles in particular are a bitch; you need to add a second level of "emitters", "active_emitters" and "free_emitters", otherwise you're measuring distance and sorting for every individual particle.

I think the payoff is worth it but it's not something you can just drop in quickly. 

Of course even then intersecting surfaces won't work.

People have been asking for a programmable blend stage for years and programmable blending would go a long way towards proper per-fragment fast order-independent translucency. Being able to select between "src + (dst - src) * alpha" or "dst + (src - dst) * alpha" based on a depth comparison should do it.