[CF-Devel] client image handling changes.

[Mark Wedel]

 I'm doing work on making the client deal with the multiple image set in an
intelligent manner, as well as moving a bit of the code into the more common
area (can't do that with the image creation, but certainly the handling of the
cache and finding images and so forth).

 But what thing I plan to do unless there is a very vocal outcry is make
cache_images behaviour the only supported option.  This is done to simplify the
code, and the cases where you would not want to use that cache behaviour are
very limited (the only case readily available is if you are playing on a server
with very close (eg, LAN) connectivity and don't ever plan to play on other
servers).

 Let me describe a bit more the changes I am doing:

First, in addition to looking for images in your ~/.crossfire directory, I have
added support for a common system wide location ($PREFIX/crossfire-images/...). 
As part of this, an crossfire-image archive will be distributed, so that
generally images don't need to get downloaded from the server.

The client now has a hash table used for caching.  This hash table contains the
image name, the local pathname to the image, and the checksum.  IT also knows
whether that image is in the public cache, or in the per user cache
(~/.crossfire/images/...)

The caching mechanism is basically the same - when the server runs across an
image it hasn't told the client about, it tells the client that image X is known
by name Z, has checksum S, and belongs  to set Q.  The client then looks through
its hash table to see if it has anything that matches, and if so, it loads it
up, or re-uses it if it had created it from previously play (so on another
server or just from re-connecting to the same server).  As it is now, the client
actually doesn't care about the set.

 If the client doesn't have the image, it requests it from the server.  It then
writes it to disk, and updates is cache tables.  Note that it never
overwrites/deletes previous entries - thus, if server A is using one image for
its main set, and server B is using a different image for it main set, your
cache still remains useful - it will just contain the images from server A and
B.  In the long term, this could of course pose a problem as your cache fills up
with obsolete images, but there is no easy way to know if an image is obsolete
(maybe a server you infrequently plays on still uses it)

 I should detail a bit more what I mean when it re-uses it.  Lets say you are
playing on metalforge - its created a bunch of images (sdl or x-server or
whatever).  You then save that character, and switch to another server (don't
quit the client, just changing where you play).  For all the images it created
(rendered) while on metalforge, it will re-use those on the new server
(presuming checksum and other details match).  Thus, it saves cpu time by not
having to re-render the images each time you connect to a new server as long as
your client continues to run.  Note the downside to this is that it uses more
memory.

 One other reason these rendered images are done is that it then makes
relatively quick to switch between sets - it just basically has to update
pointers to what things look at.

 Note that the gfx directory to override images still exist, so if you always
want to use some particular image for something, you can by putting it in there.

 While I haven't done it yet, I also plan to add support for the client to
download (as needed) and render all images the server is using before play
starts.  This increases startup time some, but then reduces potential lag during
play.  To do this is any reasonable fashion also has to use the caching
mechanism.

So in summary, here are the reasons to only allowing caching:
1) less bandwidth needed, as images will be local.
2) related to above, less stress on the server.
3) simpler code for the client.
4) Allows the client to do more complex things - if we don't cache, we never get
the image name, so
can't re-use the image data when we go to the next server.

Why not:
1) more local disk space needed (few megabytes) for the images.
2) Until the cache is built up, some rendering slowdown (as the client has send
the request to the server and await the actual image data to return, having
nothing to display in the man time - this will be alleviated by having the
images rendered before start)
3) larger memory footprint for the client, as it is storing more of this data in
memory (its unclear if this will be significant - if most the servers are using
the same images, which is typical, memory size will be roughly the same - only
bigger if you are switching between image sets or the servers are using
different image sets).

 In any case, thats where I am now - while having lots of options is nice, it
sometimes makes life more complicated and ends up not really being worth it.

 Note that I have no plans to remove the non cache image support from the server
- so older clients could still use the non cache approach.  This is basically
just the unix client as it moves forward.