Player coloring system on custom models/entities

[Ghost_Fang]

I know quake allows the player to change pants and shirt color without using a bunch of skins. How does Quake handle or do that? And how would I apply that to my own custom model or models/entities?

[frag.machine]

In software Quake, it's just a color palette trick. In GlQuake, the engine actually generates skin copies for the player model.

[Ghost_Fang]

Ok im using Kurok, which is GLquake, how would i replicate that effect on lets say a different model, not necessarily a player model and is it pretty memory efficient?

[leileilol]

it only works on clients. you'd have to rework the color processing with a new field sent by the server to work on other entities.

it's only memory efficient if you use software, since that method used a real-time palette row shift. GLQuake it shifts and makes a new loaded texture. Half-Life also does the same exact thing. This is why gl_playermip is advised for voodoo in glquake's readme (And should be advised on psp for the same reason since THE PSP IS A PSPIECE OF CRAPSP)

[Ghost_Fang]

so wait, for the PSP i should look into gl_playermip? Basically I want several or many variants of a particular enemy on my PSP game. So is that my best route?

[qbism]

The easiest way is just use multiple skins for the monster. Select the skin in qc ( self.skin) without an engine mod.

[Ghost_Fang]

well i knew that adding multiple skins was an option, im trying to avoid that option, especially for the psp, it costs memory and increases loading time.

[frag.machine]

With GLQuake one could mod the engine to generate 2 masked skins with pants and shirt colors, and using multitexture and color blending achieve the same effect. Not sure if Darkplaces works this way; I remember mh once wrote a tutorial to add fullbright textures in GLQuake using a similar way, may be a good start point if this feature doesn't exist yet.

[qbism]

If I had a PSP, I'd write a software port.

[Ghost_Fang]

Hmm, ok so what would one suggest for the PSP (to be memory efficient) and for a programmer whose knowledge lies in QC and stops at editing the HUD engine side?

[mankrip]

[mh]

I remember LordHavoc telling me that he changed the colormapping in DP to deal with this without needing new skin uploads.

Skin changing in classic GLQuake is both memory inefficient and slow. Needing to generate and re-upload a new copy of each texture at runtime is very bad for performance, and in an intense firefight this may be happening many many times per second. Try the bigass1 demo if you want a good measurement of the impact of this on your framerates (you might want to switch off dynamic lights and particles so as to isolate the impact of skin changing better).

GLQuake also doesn't mipmap player skins which causes even more performance impact at runtime, even when skins aren't changing. On the PSP, needing to use compressed textures will make things even worse as the data must be recompressed before each time it is uploaded.

By far the fastest and most memory efficient way of doing this is by using a shader and some dependent texture reads. You have one texture of the base skin with the shirt and pants areas removed, one masking out the different areas in the skin (using the RGB channels) and then just set up a colour blend. In DirectQ I use a third texture containing a palette ramp for the shirt, a fourth containing a palette ramp for pants, and an optional fifth containing the fullbright pixels which enables the same end result as GLQuake. This gives absolutely no performance impact whatsoever when skins change and I can timedemo bigass1 at something like 600 FPS.

[Baker]

Better late than never.

I have not seen skin coloring implemented in any of the PSP engines (I'm talking hardware builds, not the WinQuakey software build).

Basically, all the PSP engines operate as essentially gl_nocolor 1.

The whole TranslatePlayerSkin ordeal consumes too much memory to be implemented in a Quake compatible way on a hardware accelerated video build for the PSP.

The code in GLQuake saves the skin off for every model (unlike Quakeworld which only saves the skin for player.mdl) and allocates a texture for every player and colors it in on every color change. Like stated above, this is all client side.

The multiskin method is the only viable option.