Page 1 of 1

Player coloring system on custom models/entities

Posted: Mon Nov 07, 2011 10:02 pm
by 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?

Re: Player coloring system on custom models/entities

Posted: Tue Nov 08, 2011 12:38 am
by frag.machine
In software Quake, it's just a color palette trick. In GlQuake, the engine actually generates skin copies for the player model.

Re: Player coloring system on custom models/entities

Posted: Tue Nov 08, 2011 12:47 am
by 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?

Re: Player coloring system on custom models/entities

Posted: Tue Nov 08, 2011 1:44 am
by 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)

Re: Player coloring system on custom models/entities

Posted: Tue Nov 08, 2011 1:57 am
by 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?

Re: Player coloring system on custom models/entities

Posted: Tue Nov 08, 2011 5:59 pm
by qbism
The easiest way is just use multiple skins for the monster. Select the skin in qc ( self.skin) without an engine mod.

Re: Player coloring system on custom models/entities

Posted: Thu Nov 10, 2011 6:52 pm
by 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.

Re: Player coloring system on custom models/entities

Posted: Fri Nov 11, 2011 1:31 am
by 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.

Re: Player coloring system on custom models/entities

Posted: Fri Nov 11, 2011 2:07 am
by qbism
If I had a PSP, I'd write a software port. :wink:

Re: Player coloring system on custom models/entities

Posted: Mon Nov 14, 2011 4:18 am
by 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? :lol:

Re: Player coloring system on custom models/entities

Posted: Mon Nov 14, 2011 10:09 am
by mankrip
Does the PSP support 8-bit indexed color textures? If so, use it, and implement individual palettes for each entity with custom shirt/pants colors.

It'll require more knowledge than HUD editing, though.
leileilol wrote:it's only memory efficient if you use software, since that method used a real-time palette row shift.
Actually not. What it does is to use a custom copy of the color shading map for each client entity, and each of those colormaps costs 16 KB (256*64) of RAM. So, using custom palettes can be even more memory efficient, since each custom palette would cost only 768 bytes (256*3).

The reasons why they've done it that way in software is because everything had to use the same palette due to the 8-bit color video modes, and using custom colormaps would perform faster than adding an extra color shifting step to the drawing algorithm.

Re: Player coloring system on custom models/entities

Posted: Mon Nov 14, 2011 12:35 pm
by 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.

Re: Player coloring system on custom models/entities

Posted: Wed Dec 28, 2011 2:40 am
by 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.