[CF-Devel] Combing multipart images proposal/thoughts.

[Mark Wedel]

 I finally have some time to think about doing this, so I thought I would run
over the ideas/thoughts to the list.

Background:  currently, big monsters/buildings (say the shops) that are more
than one space are made up of multiple images.  The shop for example is actually
4 images, and not one.  The proposal is to made the shop just one image of 64x64
in size (for purpose of this e-mail, I am going to use the current 32x32 tile
size and not other tile sizes).

 As I've thought about this, I've realized making such a change in the server is
not as simple as one might have originally thought.

The main advantages of combining images is support of isomorphic graphics.  It
saves the effort of combining/splitting images, but there are scripts that do
that, so that is a minor improvement.  It has a minor bandwidth saving (as a 4x4
image only would need to get sent as one image, not 4).  IT also allows the
addition of height to objects (a hill giant could still be two spaces high, but
have a footprint of one space).

What needs to be done to support this:
any program that display graphics needs to get updated.  To my knowledge, this
currently includes the java client (unsupported/unmaintained?), direct x client,
native sdl client, gnome client, gtk client, x11 client, java editor, and
crossedit (near unsupported).  Certainly not all those need to get updated, but
I'm not sure which/how many are being used and how many people will complain if
their favorite program no longer works.  I'd only do the gtk client for sure -
any of the others would be much more up in the air.

 I would also say that the xpm and xbm support should go (no reason for it to
stay at this point anyways) - trying to support combining those into large
images and rewriting the clients for that would be a pain.

Objects/images need to get redone.  This can be done in a piecemeal fashion (no
reason to do all the images/archetypes at once - as you design the new image,
make the needed change to the archetype).  The main change to support this is
that in most (all?) cases right now the head is actually the upper left piece. 
This needs to get changed to lower right so that objects 'grow up' in height. I
choose lower right as that way when the head is off the map as sent to the
client, it is off in a positive direction (the current protocol has enough bits
for 32 positions, and since the max size right now is 25, that gives 7 spaces
you can use for objects off the map) Also, the other pieces needs to have its
face removed.

For client/display support, I figure that the object in question must have at
least one piece visible to the client map for the client to see it.  This may
not always be visibly correct, but no other reasonable way to do it (the server
itself has no idea of the image sizes, so can not know that say a 5 high tower
extends into the visible map if the base is not visible).  However, even this
adds complication (current server code stores faces and not objects on what each
space looks like - this would need to change to spaces so that it would know
that the object has a head).  Also, the actual map packing code should be smart
enough not to pack the same image multiple times (this is easy if the head is on
the viewable area, but suppose the head is not but several of the other pieces
are).  Also, the protocol needs to be extended to include face information that
is 'out of bounds'.  In the shop example, consider if only half the building is
visible (right half, which means the left half, and thus the origin is not). 
The protocol needs to say that this object has an offset of -1, ...

 None of this is overwhelming.  In more specific code development items:
1) The clients would always need to generate how the entire map looks each time
- it would be much harder to get something like 'space 5,5 changed, so only
redraw that', since it may have had tall images extending into other spaces, or
other spaces may have tall/wide images extending into it.  This probably makes
generation simpler, albeit perhaps slower.

2) The maplook structures in the client would have get replaced to contain
objects so it would be possible to know if there is a head.  But even that gets
odd, as now the more parts that don't have visible portions would have to take
up a spot in that if the head does have a visible portion, otherwise there would
be no link to the visible portion.  This does mean that the number of objects
visible on each space would effectively remain the same (the alternative is to
have the code that sends the object look through all the objects on the space
for ones that have heads, but the performance hit of all those iterations could
get pretty high).

3) The map sending stuff would need to get extended.  Probably the easiest thing
would be to make a temporary array of the head object ids that have already been
sent, and not to resend ones already found.  I think that would be much simpler
and faster than trying to look at the object and see if you have already
processed one of the squares it is on - that operation would take spaces of
object * spaces visible on map in worst case scenario.  This is only an issue
for objects that heads are outside of map view.  One note is that stacking of
these big images is no longer possible - the stacking is effectively determined
by the head space.  The right approach for the client is to probably draw from
top down (so if you have a bunch of hillgiants, they overlap in the proper
approach) - whether drawing left to right or right to left I'm not sure if it
makes a difference or not (eitherway you get overlap).  The only issue where I
think this may be a concern would be for buildings - they might hide stuff that
they shouldn't.

 Anyways, those are my thoughts - I decided to put them out in case people have
notes or suggestions or just anything else.