[CF-Devel] combining multipart images

[Michael Toennies]

I have finished the "one picture-per-multpart" feature since some month for
the server and the client. Based on this experience, i had changed it last
days.

It seems to me, you has not think out the problem, because you need some
changes to
arches and server code too.

A simple example:

xxxxx
xxxxx
xxxAB
xxxCD

You have a map of this - x are all single tiles. A,B,C,D are parts of a
multipart object -
sadly this object is only shown partial. The client has inside the map
update cmd no info
about the object. He only gets faces and layer information.

For this reason, the client has no info about the multipart object and the
position and offsets of
the single parts of the multi-object. It can be this

xxxxx
xxxxx
xxxOOO
xxxOOO
   OOO

or this:

xxxxx
xxxxx
xxxOOOO
xxxOOOO
   OOOO

In simple words - the client needs to know how it must adjust the picture
when it only draws
parts of the object. This is not as simple as it sounds - even to divide the
picture size and preparsing
the map for the same pictures will not work in the way we need - i had tried
it out (for iso, you even has
not fixed sized for the pictures).

Also, it will be very smart when 6 parts of a 8 part multipart-object are on
the map, only to submit ONE
face info - because every part shows ALL we need. Or the client will draw x
times the whole object or must
preparse and sort this out first (not easy).

And the next problem is, that the CF multipart system NOT defined a fixed
head position. A head can be on every position of as multipart object and
the offset of a tail part is then relative to this head - even multipart
objects of same size can have different part offsets because the head has a
different position inside.

Note, that even the server has no direct knowledge about which parts of a
multipart object followed
after the first drawn part on the next X-length position. The server don't
use multipart objects in this way - the server use the linked list of the
objects and recalc the map position with the part offsets.
This means, the head can be position 5,5 of a 8x8 object, The next tail part
can be 4,6 or 3,3 or whatever.

I first submited the part offset of multi-tiles to the client, but this will
give for complexer grafik
not the best result.

So i used a fixed table, where i had included all infos about possible
(legal) multiparts objects, submitting instead of x,y part ofset the table
id and the number of tail (also defined in this table).
Because this is part of the arch (new command mpart_id and mpart_partnr),
the server can submit the
needed information without sorting or analyzing and the client can simple
grap the right information.

The best is, that we avoid for this any picture analyzing - media and object
data should always divided.

The only (and really only) problem is, that we have now a fixed table inside
the client & the server.
When we change the table inside the server (normally we add a new object to
the table), we need to update the client too. But first we need for older
clients also a version test, and we simple do it with the fixed table too.
Are we changing server side the table, we simple increase the version. When
a older client connect, we know which parts of the server table it knows and
we submit (perhaps with the resend setup cmd ) the missing table entries.



>
     
     
     >
     
        I've done some investigation into what it will take to combine
     
     >
     
      the multipart
     
     >
     
      images into one part for client display.  What this basically
     
     >
     
      means that if you
     
     >
     
      have a 4x4 object (say a shop), you just have 1 64x64 image,
     
     >
     
      instead of 4 32x32
     
     >
     
      images.  The main thing this gains is that image maintenance is
     
     >
     
      easier (no need
     
     >
     
      to take the step to re-combine and then re-split to touch up an
     
     >
     
      image).  I know
     
     >
     
      some people have expressed the obnoxiousness of having to do that.
     
     >
     
     
     >
     
        Allowing for these combined images actually isn't that much
     
     >
     
      work to do -
     
     >
     
      really nothing at all in the server, and some code change
     
     >
     
      necessary for the unix
     
     >
     
      clients at least.
     
     >
     
     
     >
     
        The biggest problem are people using old clients (whether they
     
     >
     
      are the unix
     
     >
     
      ones or anything else) - whether they will display the data
     
     >
     
      correctly, or even
     
     >
     
      work without crashing (I think some of the very old unix ones
     
     >
     
      don't expect
     
     >
     
      anything larger than a 32x32 image).
     
     >
     
     
     >
     
        My thought on this is to make the new unix client available,
     
     >
     
      and have the
     
     >
     
      server send a standard drawinfo message to the user (client) if
     
     >
     
      it thinks the
     
     >
     
      client is out of date - basically telling the user to update.
     
     >
     
      Then after some
     
     >
     
      amount of time has passed (few months), people can start putting
     
     >
     
      combined images
     
     >
     
      into the cvs repository (for the most part, I don't expect there
     
     >
     
      to be much
     
     >
     
      updates, as unless the image is getting worked on, there really
     
     >
     
      isn't much
     
     >
     
      reason to combine the images that are already split).  Players
     
     >
     
      that are using
     
     >
     
      the old clients at that time would then face the consequences.
     
     >
     
     
     >
     
        The only way to actually remain backward compatibilty would be
     
     >
     
      to keep a set
     
     >
     
      of the old split images around, but that seems to sort of defeat
     
     >
     
      the purpose of
     
     >
     
      trying to make things easier by not having to deal with split images (I'm
     
     >
     
      thinking of the scenariou of adding a new archetype/image - if
     
     >
     
      you have to go
     
     >
     
      out and split up the image, that would seem to make it a bit of a bother).
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >