[CF-Devel] xpm removal???

Mark Wedel mwedel at scruz.net
Wed Feb 28 22:55:37 CST 2001


 Hmm..  I think this discussion is a good example of darths point C.

 In any case, the reasons I see for removing everything but the PNG set:

1) Smaller distribution (only one image file in the lib directory instead of
three, and this applies for the arch set also)
2) Less code (only need to support one format).  This isn't that big a deal in
the server, as that code doesn't actually care about the format, but is more an
issue with the editor and clients.
3) Easier for people to make new archetypes and images, as only one image is
needed.

 The main argument against it is that people still like the XPM set.

 I'm not sure I agree with AV's that difficulty in making images results in
fewer maps.  I would generally hope that every map maker doesn't feel the need
to put special objects with special images on each mapset.  I don't think this
is a good idea for the following reasons:

1) Even if there is still only one image set, creating a new arch and image is
still a bit of work.
2) There is no convenient way to just add a few new images/archetyps to the
server - basically, you need the arch distribution, and have to do a collect,
which makes the maps a bit more of a pain to install.
3) I think this could get overdone - if too many maps have new special unique
images/objects, that uniqueness starts to wear off.

 But I do have a few points:

 Best I know, for both XPM's and PNG's, no gamma correction is done for them in
the client.   PNG supports this, but I don't believe the client is using it (at
least not the code I wrote).

 Peter is/was working on making another PNG set that was basically in the same
style/a converted but not rescaled version of the XPM set.  This is a lot
better, in that if someone does make a new image, they still only need to make
one - this alternate PNG set can just borrow from that.  And in fact, there does
not even need to be server support for this - you could very well have an
'alternate image set' that you download, unpack into your .crossfire/images
directory, and run the client with the right options (-cache -keepcache) and it
will use these other images.  If that set is missing images, it would still get
the appropriate one from the server.

 Now for a bit of history:
Way back in the early 90's, I added the XPM support to crossfire.   The initial
xpm set was just the converted bitmaps (2 color).  Over time, the transparencies
were added, additional colors used, and overall the set evolved into the nice
set we have today.  Now I certainly hope it won't take as long for that to
happen to the PNG set.  And in fact what really moved the XPM set along was when
a few people would systematically go through and fix the images, and I think
that is sort of happening now with the PNG set.  Also, the PNG set thankfully
has a good starting point (xpm set).

 I will note that over that time, issues of different images for the same thing
arose - the losers can currently be found the arch/dev/xpm_pref directory. 
Fortunately, now days with the client doing the images, such alternate image
sets are much easier to handle.  

 Whats the end result of all this?  I don't know.  I will predict that the xpm
and xbm set will probably go away sometime before 2.0.  The question is really
if the server will have an alternate png set that can be used that roughly
equates to the current xpm set or whether that alternate support will just be
handled by people who want it downloading it and unpacking it in their cache
directory as I describe above.

    
    


More information about the crossfire mailing list