Images, was Re: [CF-Devel] arch/object changes.

[Mark Wedel]

 First a note on the removal of the xbm/xpm - I thought we had had prior mailing
list discussions on that, and it had been decided to rmeove them at some point -
that point largely being when the client would allow re-scaling to avoid the
problem of small displays.  The unix clients at least support the rescaling
(note that code should be platform and in fact image independent as it just
operates on rgba data), so I thought it wouldn't be a very big deal to remove
those images.  Although I probably should have sent out another note about it.

 Client image support:  Is the problem of installing your own image sets
actually do to more general laziness (certainly downloading and installing
images is more effort than just firing up the client), or lack of
documentation/availability?   Now support for a system wide location of images
for the client is probably a reasonably thing - that way, an rpm or other
package would know to install the images in the right place.

 My worry about supporting an arbitrary number of alternate sets is that it is
certainly possible to end up with a lot of different sets, with maybe just a
small number of alternate images.  This could get to be a real pain.  To me, the
other advantage of client side images is that the user can select on an on image
basis which ones he wants.  For example, right now if play with the alternate
set, you get all the images in that set - if you only wanted the monsters out of
the alternate set, you would need to make appropraite changes to your local gfx
in that case.

 But I guess really, it doesn't make much difference how many image sets are in
the server.  But I have the following guideline/proposal:

1) Image format for all images should be png.

2) There must be an active maintainer of each of the image sets.  If a set gets
too out of date because of no maintainer, that particular set gets removed.

3) When new arch (and image) is introduced, only an image for the main set is
required.  It is up to the maintainers of the different sets to make an image if
the default one is not appropriate.

4) There will be something like a 'image_sets' file in the lib directory.  This
file would contain things like image set number, symbolic name (running client
like -set 5 is pretty odd, but if instead, it is something like -set small, that
makes more sense), standard geometry of images (this is more relevant because in
the future, things like shops will just be one image, so the client can't look
at the image size - it needs to know something about what the normal size of the
image should be), image fallback mode (if image not in this set, try other set. 
Now that other set could have another fallback - eventually they all fallback to
0 - the main set), and description.

 There would be some extension to the protocol to request a copy of this
information so it can prevent it to the user (you could have a selection
mechanism in the client that requests this).  Also, when the client switched
some set, it would get the resolution at minimum.

5) There must be a somewhat legitimate reason for the set, eg, there must be
enough in the set to warrant it being part of the game and not just 15 images
you download off some site.  There should probably be at least 100 images before
it should become a set.

6) In terms of collection, the collect script will only collect the images for
that specific set, resulting in a sparse image file.  The server will deal with
fallback.  This results in smaller image files in lib, which means faster load
time and less memory footprint for the server.

7) naming would be image.111.x.png (the image and 111 obviously vary), with x
starting at 1 (0 is reserved for main set - in theory, those should get renamed
to that, but for legacy purposes, keeping it without that .x works).  If there
is good reason, put the .x in front of the .111 could be done - to be honest,
I'm not sure a how relevant this if - if using command line tools, none at all
(as it just is amatter of doing *.x.png vs *.x.*.png.  I can see it makes some
difference for tools that show the stuff alphabetized, OTOH, the location of the
.x. makes some difference, but only when the image has different animations - in
that case, all the ones for each set will appear next to each other  This
probably does make things a little easier, especially if there ends up being a
whole bunch of sets.

 Seem reasonable?  Other thoughts/suggestions?