On 04/ 5/10 09:59 AM, Brendan Lally wrote:
> Yeah, that's why I think there have to be different faces used in
> addition to also, so you'd construct a face name based on the types of
> items that are used, then get the colour substitutions from the items
>> And then you'll get the next step of "I'm not using any sword, I'm using a
>> flaming sword, etc".
> That's the bit where it starts to break down, when the number of
> different types of items multiplies. For cases like that, you almost
> want to have the alpha values held along with the colour
> substitutions, doing that though probably needs the construction of a
> fairly sophisticated png encoder in the server. The alternative would
> be to use single colour transparency (rather than a full alpha
> channel) but that is quite restrictive in terms of what can be done by
> an artist.
Right - I don't really have a good solution - I guess my point was more that
trying to do players properly gets tricky.
The correct solution here would be standard image alignments so you could
overlay other images on top of this, eg, something like: human image, dragon
armor image, sword image
In this way, any/all possibilities can be done. But this is still a huge
amount of work - most all items would need to get adjusted (things like armor
and weapons are scaled for inventory/ground looks, not to be 'worn' by a
character), and even all the character images would need to have standard
positioning so that the sword is placed in the right location, armor is, etc
I'm not advocating that be done - I suspect there are more worthwhile changes
to make to images before doing all that work (if nothing else, I'd suspect that
before putting in these subtle image changes, an image set with 64x64 or
something images so there is more detail available would be a higher priority)
So a basic color subsitution may be all we allow for all images, regardless of
type, and just put that in as 'this is all you get'
>> It also means that if any update is made to an image, a lot more potential
>> work is needed - if I add 1 color to an image, I have to update all those
>> different alternative faces with new information (potentially). At minimum, I
>> would have to update the face file if I change color information at all.
> Yes, on the other hand, if the colours used are not changed, then no
> change is required. The mechanism you describe below would still need
> the section names to be updated with colour numbers when the palette
> changes (though in principle that is an easier change to make,
> depending on what editor support is like)
yes - I considered it a bit better in that all the color information is
contained in the image file itself - that file could still get out of date
(someone forgets to change the color mapping), but it at least does mean that
one is not needing to change other files, and in a sense only needs to have one
tool up (image editor) to make those changes.
>> I'd rather not add anything that puts a lot of burden on folks making/changing
>> images - it could just turn off folks from doing that.
> Absolutely, the last thing I want is to make it less likely that any
> work is done on the artwork. however if there is a mechanism whereby
> images can be created and altered by the dozen rather than
> individually then it is a way to use any work done by artists more
>> My other thought is I'd prefer a system which can be used with only map
>> changes, eg, something like:
>> object human
>> color #0000ff
>> Which changes the main color of that image to bright blue (I think using RGB
>> values is better than just colornames which have a limited selection as well as
>> imprecising meanings).
> In terms of making that look 'right' it might need to be a
> hue/saturation/value offset, I know gimp is supposed to support hue
> layers as a way of doing something like that but am also aware that
> this is an area of image manipulation I don't understand well enough,
> I'd like to hear views from any artists who have experience with this.
I don't know either.
I do wonder if on the client side, it can look at existing colors and make
reasonable guess on what the new color should be.
For example, an images base color may be blue. However, I want it to be
green. In that case, it could look at the existing blue values, see their
intensity, and make the green value roughly the same (I guess it would really
have to look at the RGB values of the original to figure out an intensity, and
then use that for the target color).
But one thing to note is that while GIMP may support a lot of different
things, the issue comes down to whether the PNG file format supports it (and by
association, libpng and what the java editor uses)
Ideally, you want editor support for this, so when you say 'make this image
green', you can see a preview of what it will look like in the editor and not
have to make map, fire up client, etc.
>> When you start using face files, that removes a pure map solution (at that
>> point, I'd just say make up a bunch of different images with color variations,
>> and/or the mapmaker could do this).
>> One thought I did have:
>> The PNG file format does have support for different comment types - in
>> particular (from wikipedia), the tEXt stores data in name=value pairs (and zTXt
>> does the same in compressed format).
>> Could we use those to denote which colors to substitute, eg, something like:
>> (and in this case, the colors would be listed from brightest to darkest)
>> type of thing? In this way, all palette information (what goes to where) is
>> in the PNG file. A standard set of definitions of what the keys are (torso,
>> legs, hands, etc) would be needed.
>> This removes the need for any set of predefined image ranges, and if something
>> uses 27 colors, you just list them all.
>> One could also have some recursive type references like:
>> So a map maker could simply do something like say they want to update the
>> 'main' color, could do it, but if they wanted to update just the legs and torso
>> separately, they could do that also.
> Ok, that would potentially be a very powerful way to handle it, I
> quite like that design.
One thought - if on the client side it looks at the RGB values for each
palette entry, then ordering is not significant. I realize that ordering them
doesn't necessarily work - if all the colors as spaced roughly linearly from
brightest to darkest, then no problem, but in many cases, one could imagine
images where all the colors are quite bright, and there is not anything that is
I suppose one could add extra color entries just to try and make that linear,
but that adds extra complication.
>> The tricky part is communicating this to the client. My thought on this:
>> If the server loads a map that has a color specification, it sees if there is
>> already a index defintion with that specification. If so, it uses that.
>> If not, it creates a new one index definition and sends that to the client. It
>> then sends along that index value (16 bit value) and sends it along with the face.
>> The index definition might look something like:
>> index 124
>> torso 0000ff
>> legs 303080
>> cape a0a00
>> But really, all that could be binary values to save space (2 bytes for
>> locations, 3 bytes for color, but maybe need 4 for alpha channel?). But since
>> those indexes would be rarely sent, that wouldn't be that big a deal - the issue
>> would be more the 2 bytes to send an index for each image.
> If the assumption is that there is no index for most objects (probably
> true for most of most maps) then the map2 command could include the
> index when there is one, and omit it when there isn't. The amount of
> data sent for indicies should then be small compared to the data sent
> for face numbers.
Yep - especially since it only needs to send it when sending that image, so it
may not need to get sent very often.
> The other thing to like about that approach is that older clients just
> wouldn't do the recolouring, they would stick to the original colours.
>> Another thought would be instead of creating this index type, is we create new
>> image numbers and use that - however, that would also require extending the
>> protocol to include this color information when sending initial image
>> information - that saves bandwidth in the long run, but may have more issues to
>> make sure that everything works if the number of bmaps changes.
> That does potentially cause problems for a client that requests all of
> the faces at login, since the server can't possibly know what 'all' of
> them are any more.
Yep - and it is also still odd in that those 'new' faces are using an existing
png graphic - the only change is that it becomes a shortcut to note it should be
using a different color palette. I think just sending the palette ID as needed
is better - if it does become a problem (bandwidth wise), then perhaps a better
solution could be investigated at that time.