NQ Colored Dead Bodies

[mh]

The old way I solved this was to create 256 texture names in an array (no uploads just yet) (yeah, 256 is too many, but it's just names for now so no big deal), take (shirt * 16) + pants as an index into the array for each player, see if a texture had been loaded for that index, if not load it, then return the texture name.

The major downside is that it's not immune to someone spamming colour changes and if they manage to fill all texture slots they can impose a high overhead on your video RAM. It also needs to do the initial texture uploads at runtime which can cause a slight jerk the first time a shirt/pants combo is used. And you probably better glDeleteTextures the lot in R_NewMap too.

Nowadays I just do colormapping in a pixel shader. It's fast, it's immune to colour change spamming, it doesn't need any runtime uploads, it works with mipmaps, and it can in theory be extended to support models other than the player (in practice I don't do that yet). There's small overhead in needing an extra texture to mask off areas of the original, needing palette row textures for the colour transformation, and a few extra texture lookups too (not to mention the increased hardware requirements), but it's a very small overhead and a fair tradeoff.

[r00k]

[Spike]

why is ent->colormap even a pointer? that only makes sense with software rendering.

[r00k]

i tried changing it to int and then other areas of the code complain. dunno nothing really dereferences it but it's all kinda legacy hacky anyways...

[Baker]

R00k, check out this source: http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Searched for "SUPPORTS_COLORED"

Due to MH's notes, I stripped out a ton of WinQuake software renderer overhead.

The method I did in ProQuake 4.90 is a bit different than FitzQuake Mark V. FitzQuake Mark V will colormap everything. ProQuake 4.90 color maps only the 16 player skins (but ignores eyes.mdl and gib1.mdl, etc.) so if you get the ring of shadows, your dead bodies will still be colored.

Changes are pretty much in cl_parse.c and cl_main.c and the gl_model.c (on load looks at name of model). The changes in many ways are more about deleting things, surprisingly.

[r00k]

[Spike]

the colourmap table in software rendering is a lookup of the palette index against light level (if you've already got a lookup, you can just use a different table for each player). not really needed for gl.
vid.colormap is just the default table, and not useful to gl (other than maybe to see which pixels are fullbright).

Check for sign extension?

[r00k]

[Baker]

[Spike]

either way, casting it to an int is always wrong. :s
but yeah, just store the 1-based player number (or 0, for non-players) in there instead of a pointer to some mystical-but-redundant colourmap.

in nq you can probably get away with instantly expanding the colormap to shirt+pants as soon as you receive the entity, without even storing the colormap anywhere (note that dp's colormap=1024|(shirt<<4)|(pants) thing pretty much does this).
in fact, combined with a network protocol that doesn't spam changes when nothing happened, doing so would solve corpses 'randomly' changing colours.
(of course, not quite an option with QW, where the colormap is needed for player skins also)

[r00k]

so wojld it be better to use ent->baseline.colormap for non player ents? setting to 0 simply made black head model until the player respawned. or would type casting crash the engine afterwards?
basically colormap for players points to the player slot which is also passed from qc when a coprse is created.

[Spike]

the only use for colormap is as a player colour (or in qw, skin too) lookup.
using the _baseline_ value won't work, as the bodyqueue will have 0 values in there.
but I would recommend just storing the .colormap value and using that directly. If its greater than MAX_SCOREBOARD, set it to 0 in your parser, but otherwise just check it against 0 for 'default' and otherwise treat it as a simple 1-based player index. vid.colormap is completely redundant in a gl renderer.

yes, you have to be careful about multiple ents with different models using the same colormap value (like players vs gibbed heads, or TF's sentry guns etc). glquake simply uses the playertextures array only if the model is "progs/player.mdl". Which sucks, especially for quakerally. But any other solution requires some sort of per-model per-colour per-skin lookup, although I suppose you can update that playertextures array only if the correct entity has that colormap set and read-as-0 if the model of your non-player-entity with the same colormap differs. that would get quakerally working properly at least.
not that anyone really cares about quakerally.

[r00k]

[Baker]

GL ProQuake 4.93 doesn't have that issue yet uses a simple colored dead bodies strategy like GL Quakeworld used.

If the player isn't a player model, it doesn't use the player texture slots and instead just uses the normal, uncolormapped skin for eyes.mdl and such.

The player texture slots are reserved only only for the player.mdl last skin that was colormapped.

(Mark V does the thorough method and colormaps any skin/model combination that needs a color map, so there can be several textures per "player".)

[Baker]

Might add, thinking back ...

If you are trying to do colored dead bodies the "cheap way", one scenario to watch out for:

You join a server and you see a dead body before seeing a the actual player. If you say, "I'll just use the last skin/current skin" ... there isn't one because the player has never come into view yet.

So you will get a white skin in an engine that uses the GLQuake way of reserving some texture slots for player textures (vs. say a FitzQuake engine which, I'm not too sure what would happen. It uses pointers to textures, but I can't remember if those pointers are setup early or what.)