[CF-Devel] combining multipart images

[Mark Wedel]

 The original point of the message wasn't to go too much into the
technical details, but I'll try to quickly address them here.

On Mon, 6 May 2002, Michael Toennies wrote:
>
     
      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).
     
     
 If the client knows where the head should be, this makes it a bit easier.
In your map2 command, you communicated this info to the client - easy
enough to continue to do so.

 There is some trickiness in that if the head is at the upper left, but
the object is also supposed to be tall (extend above the square it
sits in) - there is no good way to handle that.  For those, IMO, the
only real fix is to move the head of the objects to the lower right.

Relocation of the head will cause some problems.  For some objects,
like hill giants and towers, the object itself should only sit in a single
space and extend higher up, getting displayed on the next one, but
not actually displayed there.  For monsters, this most likely will not be much
and issue, as monsters in most cases move around anyways.  For things like
towers, this creates and off by one error in the positioning on the map -
this is more obnoxious than terrible, since they won't have an entrance
where they didn't before - they really have on less entrance.

 I should restate that I don't consider this a process that will happen
really quickly.  It's not like I say 'its ok to combine images now
and update the archs', and a week later, all the archs and images have
been so updated.  I would more expect something like 'ok, I'm going
to update the towers, and I'll fix go fix the 10 maps that towers show
up on'.  Even more likely is the case 'here's a new arch with image,
and I'll put it on my new map', and that doesn't break anything at all.


>
     
     
     >
     
      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).
     
     
 Yes - sending only part of it makes a lot of sense - saves bandwidth,
and reduces logic on the client on needing to figure out that it doesn't
need to draw XYZ a bunch of times.

 This does add to server complexity of course.  The easiest approach
here is for the client to only send the bottom right coordinate in
all cases for these big images - I say that because it first enables
the client to always use a 'draw up and to the left' logic, which
means tall objects work out.  It also is easier to do - since the default
server limits the size map the client can request to 25x25, but
the map1 supports 63x63 (and map2, 31x31), for an object off the
bottom right edge, you could still send a coordinate of like 28,26.
The client obviously needs to be able to handle offsets off the map,
but that shouldn't be hard to do (unix client, thanks to the fog of war
code, already has a virtual map that is bigger than the viewable area
anyways).

 The one tricky part on this is cases where a portion of the multipart
object is visible (on the stacking), but the head is not.

 Suppose for example, a floor, pentagram, a big monster on the lower
right portion of the pentagram, whose head is in the same position as
the head for the pentagram (but is otherwise smaller than the pentagram).

 In normal situation, the floor, pentagram, and monster get sent for
that one space.  But suppose a fireball goes off.  That fireball
may be the visible object, and the pentagram may now disappear.  So
for that space, the floor, monster, and fire gets sent.  This isn't
really any different than it is now.  But in the upper left, normally,
the floor, pentragram, and fire would be visible.  Since the pentagram
didn't get sent, only the floor and fire could really be displayed.

It may not be worth it to worry about that case too much - I'm not
sure how often multipart objects are going to get obscured in that
fashion.  At the same time, by only sending the head of the multipart
objects, other parts actually become 'more visible'.

For example, that 2x2 monster used to get sent for all 4 squares - that
would mean only 2 other images could be sent for the squares it is on.
With the new system, it would only get sent for 1 square - on that 1 square,
only 2 other images could get sent, but for the other 3 it used to occupy,
now three images could get sent.


>
     
     
     >
     
      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.
     
     
 Looking through the archetypes, all but two multipart objects have
the head in the upper left.  The other two have it in the lower right.

 Given there are no objects currently with the head in the middle
of the object, it is easy enough say that all archetypes must have
the head at either the upper left or lower right.  Lower right
is better IMO for a variety of reasons.  However, updating the archetypes
to make this the case would require all maps that have those objects placed
on them to get changed.

 Its simple enough to tell the client whether the head is in the upper
left or lower right so that the client has some idea where the origin
point for the object should be.

 It is also a simple matter to add some code to the arch loader that figures
out the lower right most extent to the multipart object.  That IMO is
what we really care about.  The only case where this may not work really
well is if a multipart object is not square (or more precisely, when
the lower is not a corner.  Eg, something like

  x
 xxx
  xX

 is fine, as the big X showing the lower right is still at the extreme.
But something like:

 x
xxx
 x

 cause some serious problems, because you don't actually have an part
in the lower right.

 I'm not sure, but I'm pretty sure most the multipart objects are square.
if there are any that are not, they may need some adjustments.