Re: [CF-maps] Sprite Recolouring

[Mark W. <mw...@so...>]

On 04/ 2/10 06:35 AM, Brendan Lally wrote:
>
>>    Would it/how hard would it be for the client to do this coloring?
>> Yes, some mechanism to convey this extra information would be needed,
>> but on the plus side it means that the client doesn't have to
>> download a bunch of images that are the same except for a different
>> color palette.  Also, depending on how this is done, it actually
>> provides for a lot more potential images (realistically, there is
>> probably some upper limit of number of different colored versions of
>> the same image you want, but if in the client you convey a 256 color
>> base (3/3/2 bit rgb values let say), and have some way to specify
>> that in the arch, you now provide a huge number of possibilities.
>> And if you want to let the full 24 bit values in (figuring extra few
>> bytes of bandwidth is not an issue), you now have endless colors.
>
> I think there are several possible approaches here:
>
> 1) a different face number for each image. =>  This involves very little
> change to the server/client interaction, since they are just
> more face numbers. However it is inefficient, because the image data is
> sent each time, and the number of faces potentially spirals out of
> control.

  yep.

>
> 2) a palette number associated with each face, so that the palettes are
> sent separately =>  this is more efficient than 1, and less so than 3.
> You also would need to extend the map2 command to send the palette
> varient. =>  the least distruptive way to do this would probably be to
> have a 5 byte variation on the image information, so that the options
> then become:

  I'm not sure how it would be done, but on the map/arch level, I was thinking 
of being able to say something like 'color purple', server sends that 
information down to the client, and it does appropriate substitution on the 
image to make some aspects of it purple.

  Digging into the protocol specific may be getting ahead of ourselves, but what 
you describe works.  What would then have to be described is what that one byte 
means.

  I'd also envision that the 'major' color of the image is altered, ie, the 
robes, and not a lot else.

>
>
> 3) Try to send the individual colour substitutions. While this would be
> potentially more efficient, it also causes a question of how to store
> them sensibly, I can't think of a coherent design for this at the
> moment.

  I can't think of any real way to do this - it would require the on the arch 
level get tied pretty specifically to the image (so you know what the base color 
numbers are and what to map them to).

  What I'm thinking is really point #2 above.  Eg, I'd like this wizard to 
appear green, not red, and can just specify that simply.


> Yes, I'd suspect at a minimum, the existing images would need to be
> re-indexed less efficiently (so that for example colours 1-10 are hair
> colours, with 1 being the highlight colour through to 10 being the
> darkest shadow in the hair.
> 11-20 skin tones
> 20-25 facial features (nose, eyes, mouth)
> 26-35 torso
> 36-45 lower body
> 46-50 feet/shoes
> 51-60 weaponry (if held)
> 61-70 headwear
>
> and so on.

  I think that is going overboard if all we are talking about is a single color 
specification/override for any given image.

  In that case, you just need something like 'colors 1-10 are what colors should 
be substituted, with 1 being the brightest, 10 being the darkest' type of thing.

  But this is because I'm thinking of just wanting to change the 
major/significant color of an object - trying to adjust all those different 
colors is going to be more of a headache.

  (even 10 colors may be overkill, but I'm thinking that some images certainly 
do use different shades of the same color, so you just can't say substitute the 
first color)

>
> Not many images can conform to something like that currently, and it
> would bloat the PNG files to include what would be in many cases
> duplicate colours (eg, the blue of a cloak may be the blue of the eyes,
> they would need to be different colours in the PNG file in order to
> recolour one without getting purple eyes because a cloak changed
> colour).
>
> The PNG spec does permit duplicate colours so that isn't a
> problem, but it probably does need someone with artistic talent (rather
> than an ability to play with some sliders in the gimp) to handle it.
>
> Also there would probably need to be a policy regarding RGB png files
> (different to colourmapped ones, which have a defined palette)
> somewhere around 95% of the existing images are colourmapped, but there
> are also over 100 RGB images (and a number of greyscale images, which
> are still hanging around).

  There is probably also not a need that every file have a proper palette set up 
- for some, it would seem that changing the color would be odd.  On the other 
hand, maybe odd effects would be interesting (green food?)

>
>>> 3) If they are added, should there be some guidelines about
>>> where they will tend to be used? (eg, light blues are
>>> considered fashionable in navar, greens in darcap, etc)
>>
>>    I don't know.  At some level, it could be handy to remember that I
>> talked to the red courier in navar for quest information, and he is
>> the one I should return to - so having a rainbow in each city makes
>> it visually easier to identify the one you need to talk to.
>
> I was thinking also in terms of world design here, so saying that the
> colour of the imperial post office is yellow (say), therefore all their
> employees will be wearing yellow uniforms (rather than looking like
> everyone else on the street).

  That makes sense - certain professions may be colored alike as you describe. 
Same true for town guards - anything you would generally think of wearing a 
uniform.  But for random folks, I'd think they would wear whatever they feel like.