GLQuake and deadbodies not being colored

[Baker]

I have always found it annoying that dead bodies don't get colored in GLQuake. Quakeworld, they do. And DarkPlaces since something like build 73 way, way long ago in something like 2002 ... they do.

The reason deadbodies don't get colored in GLQuake works like this:

1. With OpenGL, you must have player texture slots. GLQuake uses 16 (Quakeworld uses 128).
2. If a player changes color, the player texture gets recolored and re-uploaded. This has a performance cost.

Taking a very conservative approach with the following boundaries and sticking with the 16 player texture slots, it is possible to essentially get colored player bodies for free because the dead body's colored skin is already uploaded as the player skin so you just bind to it.

Well ...
1) If you are running id1 Quake and not something with several player skins
2) Or something with multiple player models (FVF comes to mind, so does Slide).

And ... if you stick within the bounds of 16 player textures and ONLY using those slots to color bodies, you also have the problem that the client doesn't always know what player model a player is using (if a player isn't in view, for example).

For example, if someone gets the invisibility ring, they switch to eyes.mdl

Interesting problem ... if sticking to the 16 player textures concept. Almost requires at least a mild skin manager like Quakeworld uses.

[r00k]

[mh]

[Spike]

[Baker]

[mh]

What I do is keep 256 texture slots spare for player textures (16 shirt * 16 pants). Whenever a player colour changes it checks to see if a texture is already available in that slot; if so it uses it, if not it translates the base skin and saves to that slot. All 256 slots are cleared down on a map change.

Since a texture is initially uploaded when a player joins the game this means that the actual brief stall during gameplay is kept to a minimum and definitively doesn't happen when a player dies and is respawned. It just pulls the correct pre-uploaded texture from the appropriate slot instead.

It's quite possible to DoS a person using this method of course; a malicious player could quite easily switch between all 256 available colours over a short time period and flood your video RAM. But that needs to be balanced against the genuine requirement for honest players to not have stalls and hitches during busy games when people are being killed and respawning continuously.

A possible solution would be to only keep the 16 (== MAX_SCOREBOARD) most recently used skin textures, and also to automatically clear down a skin texture if it hasn't been used in a certain period of time; say, 5 seconds. I'm dubious about the latter but the former should work.

Looking forward to seeing what Baker comes up with here.

[Spike]

from the sounds of it, baker is going to generate a new image for each and every entity.
Personally, I think some code that uses the private texture of the player when the ent matches the model for that colourmap's model is sufficient, and regenerate the player's private texture any time the players model changes to anything with a size above 16*16*16 (ie: not a head/gib) (if they're not visible and their colour changes, like at first spawn, then assume they're using the baseline model and generate colours based on that, so corpses change instantly before seeing the player).

A few colourmapping hackable facts...
Corpses of a player will have a colormap set to the same as the player's ent number (cl.scoreboard[colormap-1] refers to the client's player-specific info for that corpse).
Corpses or players can be gibbed heads. Such gibs will have the same colourmap.
TeamFortress and other mods use the colormap field for sentry guns. This is most noticable, for me, with CuTF's teleporter pads.
Nexuiz uses colourmaps for dropped weapons.
Generaating new colourmaps on the fly will induce a stall. You'll not really notice it for a single player (think lightmaps) but for multiple players all doing it at the same time it might be noticable. Certainly avoid disk access.

[mh]

The fact that player textures need to be resampled to powers of 2 doesn't help either, as well as the fact that GLQuake sends them through glTexImage instead of through glTexSubImage. All horrible horrible stuff.

I'd already got the corpse colormap == player number thing, but it's good useful info for everyone.

[frag.machine]

[mh]

[Baker]

[Spike]

[Baker]