[CF-Devel] XPM-PNG image set completed! (mostly)

[Mark Wedel]

Peter Mardahl wrote:
>
     
     
     >
     
      Hello,
     
     >
     
     
     >
     
        I've created a facility by means of which some xpms or pngs
     
     >
     
      can be replaced with custom images.
     
     
 <snip snip snip>

>
     
     
     >
     
      You can *drop* any .xpm or .png replacement of anything mentioned in
     
     >
     
      bmaps.paths in alternate_images
     
     >
     
      and that image will prevail.
     
     >
     
     
     >
     
      I think that we should get rid of .xpms and .xbms from crossfire now as
     
     >
     
      being obsolete.
     
     
I think before long, we really need to figure out the end goal for this
alternate PNG set.  I see 3 reasonable possiblities:

1) server has 2 (or potentially more) png sets, and the client can ask for
'standard png' or 'alternate png' sets. 
2) the alternate png set is just a temporary measure and eventually will go
away, with one 'good' png set.
3) really move the image stuff to the client, with the server having images
really only because new archs/maps/images may get added faster than the client
gets updated.  With this, the server only needs one 'fallback' image set.

 I personally like #3.  I have a feeling most commercial games use this approach
(images are held by the client, and not transmitted over the wire), but they
have perhaps more luxury in that the server is not likely to have new images
added without them also making an update for the client (crossfire could of
course do this, but if you get a bunch of people making new arch's and maps,
this would be harder to do - end result would probably be image supplement files
for each server you would need to grab via ftp or the like, which would be a
pain).

 This would require some changes for the clients.  What I would probably do is
something like:

1) add an client-images download packages.  This really might just be the
crossfire.png file.
2) extend the client to look for the master client image file in some standard
location (client-libdir), so that each user does not need to have a copy of all
that in their home dir.  Do provide a command line option to use some other
image file.  Reason for this:  If you are someplace where a lot of people are
playing crossfire, you would prefer to have as few duplicate copies of the
images around as possible (disk space as well as simple configuration issue),
but at the same time, if multiple ones exist, some people might like different
versions.  For non unix clients, this can be somewhat a bonus, as they could
distribute their default image set in a format more native for that platform.
3) Client, upon start, would look at that master image file and load the images
up , knowing that these are the master images, and use caching as default.  When
it gets an image request, it looks in its set of master images for that name,
and if it finds it, updates the 'display' list appropriately.  Only if the image
does not exist in its master set will it then look in its cache directory, and
if not their, request it from the server.  When exiting the server, the master
images would not be touched - only the 'display' list would get reset.  The
advantage of this is that when going from one server to another, it will not
need to recreate all the images.  It also means that you get to use your
preferred image set, no matter what the server may be using.  Disadvantage is
that this uses more memory (all images created at startup), which may raise the
hardware requirements for the client machine some.

 Thoughts?

 To me, the advantage of the above client side approach that as the player, you
can decide what images to use.  Peters alternate set currently only lets the
server admin decide what set it will use - it may very will be possible that the
server you want to play on has the 'bad' set.  While you can sort of deal that
with the image caching feature, it then becomes tricky to get an updated 'good'
set if you turn off the update if checksum differs feature.

 Just as a note, until I update the client png display routines with the new one
the editor currently uses, getting rid of xpm is not an option - the png set
will not work on an 8 bit display, simply because it uses too many colors (more
than 256 for the entire set), and it has not fallback mechanism when it can't
get the color it wants.  My new png code has a basic 'match closest color if we
can't get our exact one' feature, which actually does a decent job, and does let
you display the png set on an 8 bit display.