Dynamic player palette swapping

[fromhell]

another brainfart


RENDERER: Find special _colors.tga texture loading with a player texture (i.e. loading models/players/sorceress/skin.tga also checks models/players/sorceress/skin_colors.tga)

if found, mark the loaded shader as special colorable shader, internally rename the shadername after the relevant clientnumber that is using it, and load _colors.tga into SYSTEM MEMORY (don't upload the texture until we're done blending on)

Check connected client for color parameters set through some cl_ cvar, like cl_playerColors "24 75 33 22"

Numbers represent pre-defined gradient ramps from external files (similar to palette ramps in quake), maybe gradient maps could be gimp format or some other plain text?

_colors.tga has 4 channels, one channel each dedicated to a certain chosen gradient ramp. All channels (including alpha values) blend additively on each other with their ramps. Alpha channel isn't really an alpha here, it's a 4th color.

Then this result is additvely blended (or overlaid with 0 value being alpha?) on the base texture. Alpha unaffected (if any)

Like the scratchpad textures, a client player slot would allocate one of these textures (and only ONE!!!!!!!!!!!!!!!!!!! ONE)


ADVANTAGES:
- colored skins with nice colors similar to fighting game palette swaps
- lighting works
- vertex lighting works, as this approach would function with single stage texturing
- art can still be art and still have base color underneath
- really really cool sense of individuality

DISADVANTAGES:
- maybe slightly cpu choking at deferred loading (MMX optimizing is theoretically feasible for that however)
- someone could flood it to cause some slowdown (i.e. some clever person wanting a rapid color cycling script, this was a big problem in the glquake days)
- more texture memory use if everyone's the same character on different colors
- JPEG format would ruin the color ramps and DDS would be hard to process with too

[Gig]

Interesting idea, although maybe a little complex.
The idea of changing the color of some details of your clothing more or less the way you set your railgun effect colors may be nice...

What about team skins? Would this system be disabled during team modes, to prevent possible confusion due to too many "red" details in a "blue" character?

[fromhell]

Having this involved with team skins would be a waste.

[cheb]

A great idea (I'm sure I suggested this some years ago but no one understood me)

more texture memory use if everyone's the same character on different colors

Think in terms of worst case scenario: your best FPS doesn't matter, it's your worst that defines the perception.
In this case, worst case is when every player uses a unique skin.
There is no difference between that and different palettes.

P.S. Just quoting that book about making Quake, AFAIR it was like "no one will care if your best FPS is 60 if your worst FPS is 15, it's better to use a solution that gives constant 30 fps" or something like that.

P.P.S. No one uses palettes nowadays   When I'd finally tear out of the bog of routine stuff, the first thing I will implement in my engine would be palettes. Built right into the basic GLSL fragment program  

Having this involved with team skins would be a waste.

On the other hand, IF your basic skins are B&W (dark trousers light shirt / light trousers dark shirt / checkered / striped / swirly AND you slap palette swapping on top of that, you get tons of unique variants, with most players looking unique.

It's like 2 dimensions multiplying, if you have like 5 patterns x 5 palettes you already get 25 unique variants.
And making patterns could be relatively quick and dirty.

Would even work with team skins IF you allow to vary palette colors inside a certain gamut (yellow/orange/red for the red team, cyan/blue/purple for the blue team)

[Neon_Knight]

In that last case of yours, perhaps for team games there could be a default hue (¿even a range of saturation?) forced onto all of the players, so they can still be recognizable while avoiding confusion.