Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: er...xbmtoxpm???



Kjetil Torgrim Homme <kjetilho@ifi.uio.no> writes:
>
>Actually, no - the RGB values should be compensated for. Let me
>rephrase that: "gold" should always look the same, but the RGB values
>can differ wildly from machine to machine. OK, this is theory - most
>sites have one rgb.txt for all of their differing monitors...
>
>How does this affect us? Well - we'll need to choose the real RGB
>values, not the names, or else we may risk having lots of pixmaps with
>_similar_ colours. Mark, I guess your rgb.txt file is as good as any.
>
>BTW, you chose the same selection of colours I was going to suggest :-)

 Are you saying that the actual RGB color values should be put into
the XPM files (ie, instead of 'red', have it ff0000).

 I really don't know what this will gain.  The XPM library can either
look it up at load time, or it is defined as that value.

The only time this would matter is if the rgb.txt files have different
definitions for the colors.  And if this is so, assumably it is so that
the colors look close to the standard on differing monitors.  Embedding
the RGB values will not make any difference.

 But as an example, I have 2 color sun 3/60's.  The color between the
two monitors is slightly different.  Whether the RGB color is embedded
in the XPM file, or the name is used, the two objects will look slightly
different on the two monitors.  The best way I could fix that would be to
to have one rgb.txt file per machine, and tweak the color values until
they match.

anthony@aaii.oz.au wrote:
>Has anyone thought about non-colour machines, and picking equivalents
>for each of the colours?

 There are two non color machines - black and white (in which case,
equivalants are not necessary), and greyscale machines.

In terms of black and white, whether a color should be marked as black
or white can depend on the item.  In some cases, certain colors might
be meant as foreground (and thus black), and in other cases, that same
color might be part of the background (and thus white.)

 For greycale machines, I would first be interested in seeing how
the XPM library handled colors that are loaded (does it turn them into
an approximate grey?)  But in any case, what shade of grey it should be
should probably be determined on whether the object is in the foreground
or background.

quinet@montefiore.ulg.ac.be (Raphael Quinet) wrote:
>
>There's no problem, because you can use symbolic names in XPM files.
>Why not use the symbolic names "foreground" and "background" (or
>"face_foreground" and "face_background") in every image?  You can then
>bind a value to the symbolic name at load time, by putting the desired
>values in the XpmColorSymbol structure.
>
>
>

 I looked into the symbolic names.  The way I read it, you can get
the pixel value of that symbolic color, and this change the color of
that pixel.

 However, as I understand it, it would change the color for all objects
using that shape.  In other words, you could not make foreground of some
face blue, and also red, and display it at the same time.

 And this also makes the code a bit more complicated.  Because objects may
use several shades of a color to make the pixmap look better.  You then
need to change all the color elements to the new color.

 I suppose (what maybe Raphael was talking about) is have the same face
for numerous archetypes, but just keep one copy on disk.  As you laod them,
then color them for the different archetypes.

 This saves a little disk space, but makes the program more complicated.
And since the crossfire.pix file can be gzip'd, the size savings is
very small.

--Mark