On Thu, 01 Apr 2010 22:00:25 -0700 Mark Wedel <mwe...@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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire