[CF-Devel] xpm removal???

dnh dnh at hawthorn.csse.monash.edu.au
Wed Feb 28 23:46:43 CST 2001


On Wed, 28 Feb 2001, Mark Wedel wrote:

>
     
     
     >
     
       Hmm..  I think this discussion is a good example of darths point C.
     
     
why yes, I do believe it is (to quote David Eddings).
 
>
     
       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)
     
     
I don't see this as a big problem, in todays market 1 gig games are not
uncommon. Also most players choose only one set anyway.. if caching is on
that still only constitutes 1 set.

>
     
      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.
     
     
This is certainly a BIG point. With the current system you need 3 sets of
libraries to get all the features and at least two for it to compile
properly (AFAIK). With only PNG supported this would be reduced to defn
only one. 

>
     
      3) Easier for people to make new archetypes and images, as only one image is
     
     >
     
      needed.
     
     
This is the killer, I generally stopped making images after the 'Skree'.
To create one fairly poor 2 x 2 monster took more work than I could really
be bothered doing constantly (especially considering it isn't even very
good).

>
     
       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:
     
     
I agree with AV. Map makers love to make unique maps that is a major part
of _creating_ something. For example Peterm only makes a mapset when he
has something new to add. I know I wouldn't want to create a whole set of
maps and find that most of my plot, or monsters or even items were
repeated else where. To make a new monsters is something to be very proud
of, and something to make alot of extra interest in a map. I loved the
first time I found a sandy not because it was worth alot of points, or
because it looked cool, but because it WAS the first time I had found one
(or three). I still haven't found a postman =).

>
     
      1) Even if there is still only one image set, creating a new arch and image is
     
     >
     
      still a bit of work.
     
     
Most mapmakers are willing to put in that work to make something to be
proud of.

>
     
      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.
     
     
Again, most mapmakers are more interested in a good map than in a abit of
work.

>
     
      3) I think this could get overdone - if too many maps have new special unique
     
     >
     
      images/objects, that uniqueness starts to wear off.
     
     
IMHO I don't think we CAN over do the amount of monsters items etc. If
everything is properly balanced the sheer massiveness alone of the game
would certainly be a key point to many players. It is very exciting to
have a world that really is a world. Different cultures for different
regions.. etc etc.. adds alot of flare to a game that may otherwise be
boring (not that crossfire is boring).

>
     
       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).
     
     
PNG does support it (PNG supports just about everything =). I think Mich
would probably be very interested in doing just that, currently though
there is no one working on a linux client AFAIK.

>
     
       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.
     
     
Peterms set was widely considered better than the scaled versions of the
xpms in PNG.

>
     
       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.
     
     
Yes, I would like to see two sets of PNG (or more as we get bigger).
Currently I see a need for front view and the more 3D appearing view of
the current PNG set. Over time this may change (10 years is along time
though) but I think we shouldn't look to far ahead it may cause alot more
problems than it fixes. I would say that that perfect stability of the
server is a more pressing issue than the PNG set graphics right now. I
would still absolutely love to see some work done in it though.

I think Mark has made some very important points here so i thought it
valueable to add my thoughts. I think EVERYONE should say what they think
now.. or forever hold their peace.

dnh


>
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >
     
     
     
    


More information about the crossfire mailing list