• Advertisement
Sign in to follow this  

best way to handle layered sprite colouring

This topic is 422 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'm thinking about the best way to handle sprites with user selected colours, this is most commonly seen in an RPG where the player can choose for example skin and hair colour and perhaps one or two clothing colours as well.

So clearly the starting point is a layered image. But I see a couple of ways to go from there. We could just store the layers separately and draw them one at a time with the appropriate colour.

Or we could try and do something clever with the fragment shader, say we bind a greyscale texture as a layer map and use this to index into an array of colours passed as a uniform. This sounds simple enough, but I have a very poor feel for whether it would actually perform better. I suppose I should just try it. One thing I don't like about it is that it would be nice to use the same shader to draw things like spell particles and projectiles which are very unlikely to have multiple layers, making this somewhat wasteful.

Also I was looking into how the old infinity engine games store their character sprites and see something interesting:

[sharedmedia=gallery:images:8306]
 
It looks they avoid storing the pixel layer map separately by storing it in the image hue values, the image has around 6 different hue values that are all multiples of 60 or very close. If the user is choosing a colour, I suppose that means the sprite itself is basically providing brightness and saturation values, is that correct? Although I see the image is mostly completely saturated, only varying around some highlights. I don't actually understand colour that well. But in any case what do you think of this idea?
 

 

Share this post


Link to post
Share on other sites
Advertisement

todays graphics cards have lots of memory.  gigabytes of it.

 

one solution could be to store a color with a known value that you can reference later in the actual texture image.  then at run-time if you have say 4 players, load 4 instances of the image from disk.  replace the known reference color with the color of the player.

 

then you just draw as normal.

Share this post


Link to post
Share on other sites

It looks they avoid storing the pixel layer map separately by storing it in the image hue values, the image has around 6 different hue values that are all multiples of 60 or very close.

This makes it look like a mask.

If I had to take a guess at how it worked, they probably assigned each part of the mask by dividing the color bit count (255/4 = 63.75) then retrieved this normalizing it to a black and white image then multiplied the color to the normalized mask.

The advantage of the above mask is that in theory you can have 255 separate color schemes although each scheme added would reduce the quality of every other color scheme.

 

Because in modern games you will almost never use more than 4 colors for a object you can just use a RGBA texture to store the mask; storing each color scheme in one channel and then multiply the color you want with the channel.

Share this post


Link to post
Share on other sites

todays graphics cards have lots of memory.  gigabytes of it.

 

one solution could be to store a color with a known value that you can reference later in the actual texture image.  then at run-time if you have say 4 players, load 4 instances of the image from disk.  replace the known reference color with the color of the player.

 

then you just draw as normal.

Yes it might be simpler to just copy the image. The only thing there is that I thought it might also be nice to be able to do more dynamic things with the mask, like with spell effects for example. You could have barkskin spell that changes the colour of the skin only, or a burning blood spell that gives the skin a pulsing glow. (I'm not sure how this would look in practice.)

Share this post


Link to post
Share on other sites

Start with brute force. Don't waste time trying to get fancy until you've proved you have to. 

Worry about one effect at a time.  You can combine them later.  If you don't KNOW you need a capability, adding it is over-engineering.

in general, follow the KISS principle in design - i know! i know!  - its boring, no glory coding, no cool engineering stuff !    - but it tends to result in better designs - in all engineering disciplines, not just game development.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement