Tuesday, December 8, 2009

Fun with Player Skins

I've just been making the player skin translation system on DirectQ actually work properly. This is a problem on account of the way Quake handles player skins. We basically have a situation where a player skin is translated in one of 3 circumstances: (1) when a player enters the game, (2) when a player's model is changed, and (3) when a "color" command is issued at the console (or via the Setup menu).

What this means is that any busy deathmatch will have lots and lots of runtime translations as people are killed and respawn (which counts as entering the game, oddly enough). Run the bigass1 demo (look for it on Google, but be careful what links you click on...) to see the effect. Lots and lots of hitching and stalling as skins are repeatedly updated.

A 16 player deathmatch in a confined space will always result in lots of killing, so this is something of an extreme example - or is it? Even with 4 players things will get fairly busy in some of those maps, so it seems a sensible thing to do.

I had previously implementing a caching system where skins were retained based on the player number, but that didn't quite work out as I had failed to take account of the fact that the player number might change. So I've now changed it to retain skins based on the colour, which means a cache of up to 256 skins.

The plus side is that it's now utterly reliable, the negative side however is that it can cause some fairly heavy video RAM usage. To alleviate that I'm clearing down the cache at each map load, and also clearing individual entries if a skin colour changes (via the "color" command or the Setup menu) and no other client is using that skin.

Overall it's a nice result and a good compromise.

4 comments:

=peg= said...

Sounds good :)

Andy said...

Agreed. I can't wait to give it a go.

Baker said...

I love reading in-depth analysis of what the engine is doing, how it is doing it, how it can be improved.

=peg= said...

^^ That! :D