Re: er...xbmtoxpm???

[Mark Wedel <>]

 Should XPM library be included:  PRobably not, since it is not required
to compile crossfire (you can just turn the XPM option off.)

 Migrating to only XPM files should be done eventually.  Almost
certainly not before we move to client/server (this way, the client can
hold a local copy of the XPM files on disk instead of downloading them
from teh server at each startup.)  When using just bitmaps, the time it
takes to download (if you have a slow connection) is measurable.

 While XPM files are inefficent on disk, I don't think they are that
bad in memory.  Also, the crossfire.pix file can be compressed for
great savings (knock it down from over 1 megabyte to about 120K I believe.)

 XPM files should be convereted by hand for best look.  However, this
does create some problems:

 1) Several archetypes may use the same face, and color it differently
 2) This means that a unique face for each archetype that wants to color
    it differently is needed.
 3) the color foregroudn and background elements in each object description
    now only become useful for magic mapping.

 None of these are great problems, but it will increase the number of
XPM files.

Other notes:
Location of XPM_LIBDIR in crosssite.def:  Like motions options in that
file, many only need to be set if you want to do someting unusual.  If
the XPM library is in the standard place, XPM_LIBDIR should not be
needed for the linker to find it.

 Colors:  The set Petri posted looks good.  But there is no real reasy
(easy) solution.  IF you just use the base 16 (or is it 12) that is used
right now, pixmaps will not look a lot better except for the outlines.
However, people obviously can't just choose whatever they want, or the
set of colors may become above 256.

 but I do believe that the routines in the XPM library that creates the
pixmaps will do color matchin, if it can not allocate the color requested.
There are also other ideas for allocating colors.  216 colors could be used,
which each R,G, and B element having 6 possible values.  125 could be
done in the same way, but with each RGB element having 5 possible
values (0, 64, 128, 192, 255).  This gives a wide color selection, but colors
are not necessarily close together.

 However, for now, I think we should restrict ourselves to the Petri
posted, with a few additions.  Here is the list:


        00 - transparent
        01 - black
        02 - dark gray
        03 - grey
        04 - light gray
        05 - white
        06 - dark red
        07 - red
        08 - light red
        09 - dark green
        10 - green
        11 - light green
        12 - dark blue
        13 - blue
        14 - light blue
        15 - dark yellow
        16 - yellow
        17 - light yellow
        18 - dark magneta
        19 - magneta
        20 - light magneta
        21 - dark syan
        22 - syan
        23 - light syan
Additions from me floow: