Player coloring system on custom models/entities
-
- Posts: 336
- Joined: Thu Nov 12, 2009 4:37 am
Player coloring system on custom models/entities
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?
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Player coloring system on custom models/entities
In software Quake, it's just a color palette trick. In GlQuake, the engine actually generates skin copies for the player model.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
-
- Posts: 336
- Joined: Thu Nov 12, 2009 4:37 am
Re: Player coloring system on custom models/entities
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
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)
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)
i should not be here
-
- Posts: 336
- Joined: Thu Nov 12, 2009 4:37 am
Re: Player coloring system on custom models/entities
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
The easiest way is just use multiple skins for the monster. Select the skin in qc ( self.skin) without an engine mod.
-
- Posts: 336
- Joined: Thu Nov 12, 2009 4:37 am
Re: Player coloring system on custom models/entities
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.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Player coloring system on custom models/entities
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Player coloring system on custom models/entities
If I had a PSP, I'd write a software port.
-
- Posts: 336
- Joined: Thu Nov 12, 2009 4:37 am
Re: Player coloring system on custom models/entities
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?
Re: Player coloring system on custom models/entities
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.
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.
It'll require more knowledge than HUD editing, though.
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).leileilol wrote:it's only memory efficient if you use software, since that method used a real-time palette row shift.
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
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Player coloring system on custom models/entities
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..