[crossfire] [CF-maps] Sprite Recolouring

[Brendan Lally]

On Thu, 01 Apr 2010 22:00:25 -0700
Mark Wedel <mwedel at sonic.net> wrote:

> On 04/ 1/10 05:46 PM, Brendan Lally wrote:
> 
> >
> > 1) Are recolours worth adding as a way to increase variety of NPCs?
> 
>   For NPC's, I'm not quite sure about.  However, for PC's, this could
> certainly be interesting (provided we have a way for players to
> choose this).  But I'd also say that more diversity is seldom a bad
> thing.

I started off with NPCs for two reasons:
1) there are a lot more of them than there are players
2) they can be changing them in the map files requires nothing more than
using sed appropriately.

I was also looking at creating the png file directly in the arch/
folder, so that none of the server-client interaction was affected.

I'll carry on with writing some C code to handle palette extraction and
substitution, since if it isn't used, it may form the basis of a client
patch if it is decided the client should redraw PNGs.

What you are describing now is potentially much more powerful, although
also more complex. I've copied in the main CF dev list because that is
more a server-client discussion.
 
> > 2) does the answer to question 1 vary depending on how they are
> > implemented? (lots of different PNG files, or a script to rewrite
> > the palette entries of a single png file, maybe as part of the
> > collect step)
> 
>   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.

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:

2 bytes: This is only the face number.
3 bytes: <face num>[<smooth>|<animspeed>]
4 bytes: <face num><animspeed><smooth>
5 bytes: <face num><animspeed><smooth><palette variation>

there would also need to be some either some extension to
image2/creation of image3 in order to send the palette variations ahead
of time, or a separate palette command

Client side, the clients would need to hold the alternate PLTE sections
of the png files and substitute them in depending on the palette
variation they are sent. This could be quite quick if the variations
are stored in an array associated with the face but it would mean a
fair bit of custom PNG mangling. For the C client, this shouldn't be
too bad, I don't know what that would be like for 

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.

 
>   This clearly changes the logic for the client - it would need to
> color them real-time in that case (for 24 bit values).  Conceivably,
> for 8 bit values, it could just set up an array and fill that in as
> it actually needs, and even in worse case, on modern systems,
> probably not a high burden on memory (and if done on the client, the
> client could perhaps choose not to even do that coloring to save
> memory or reduce the palette to 16 colors or something).
> 
>   But I have no idea how hard it would be to do this on the client -
> I would suspect that some form of standard for the images would be
> needed.

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. 

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).

> > 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).

Brendan.