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

[Mark Wedel]

Andreas Vogl wrote:

>
     
      (snip) As Mark suggested, it seems much wiser to allow scaling,
     
     >
     
      and maybe better customizable arrangement of the client's windows.
     
     
 The gtk client does allow a split mode, so you can arrange them however you
want.  But I can certainly see people playing on relatively low res displays
(like laptops) wanting every bit of space they can get.

 One other advantage of scaling is that more information can be provided in the
inventory and look windows, thus they do not need to be the same size.  With the
default font at least in the gtk client, its bound probably does not extend
beyond 16 pixels.  So the images for the inventory could very well be scaled
down in half, the text would still draw without overdrawing the line above, and
you basically just doubled the amount of information.  this in itself could be
useful for low res screens.

 I'll poke around on resizing code for the client.  I don't think it should be
too hard.

 If retaining 24x24 images really is a big thing, I would rather convert them to
png than keep xpm - at least that eliminates a bunch of dependencies.  But IMO,
there was lots of dicussion/want of supporting only 1 image form.



>
     
      I think we should handle this "overlapping problem" or we might
     
     >
     
      regret it later. My idea would be to store the image sizes (how many
     
     >
     
      spaces the image "touches", like 2x1, 3x3) by the server.
     
     >
     
      That way, the server could easily figure out which objects reach into
     
     >
     
      the client's vieable area and send them along.
     
     >
     
      Moreover, this would allow to update certain squares of the viewable
     
     >
     
      without sending *everything*.
     
     >
     
      Image sizes would really be a small amount of data and it can be
     
     >
     
      generated at server startup, while loading the pngs.
     
     
 This is reasonable.  There is some performance hit (as the squares outside the
map size the client actually displays needs to be examined for this).  OTO, this
simplifies other areas - this size information is really a face attribute, and
not an object attribute, which means a lot less code needs to be updated in the
server.  It also means that invisible sections of the big objects (invisible
because the one main face extends over them) does not take a slot in the maplook
structure for a space, so you get more images per space.

 As I think about it, this is really the way to go, because we no longer need to
try and track if we have sent that big image face to the client - we now just
treat it as a normal image, and since we examine spaces outside the bounds for
images that may extend into it, it works fine (we look at these out of bound
spaces, you look at the geometry information for the image to see if it extends
into the visible map).

 The only alteration to the idea would be that the image sizing information
would be something the user puts in the face information, and not computed.  The
reason for that is several: 1) If the server code computes it, it now needs to
know about the image format in question (ie, be able to read the actual png
data). 2) If another image style is used (say isomorphic), the geometry from
those images may not make a lot of sense if the server tries to figure out the
information (I recall the isomorphic images were something like 56 high just as
is?) 3) Human entry of this information will typically be more reliable -
remember, with this revised scheme, there is no requirement than images be
multiple of 32 wide - IF you want to make something 1.5 times higher, 48 pixels,
this could now be done.  Suppose instead you make it 1.2 (say for ogres) - this
is around 40 pixels.  The case could be made that this should extend 2 spaces,
or that it should only be one.  If its the server figuring this out, you don't
have that choice.


>
     
      The overlapping problem I mentioned above for example can only be solved
     
     >
     
      by the server, unless the whole map gets sent to the client.
     
     >
     
      Similar, the server has to decide what images the client gets to see
     
     >
     
      and in which order.
     
     >
     
      I believe the client should get as little information as possible (to save
     
     >
     
      bandwidth). If that means the server must do some graphic-related work,
     
     >
     
      still better than lagging the client.
     
     >
     
      If there is a way to both save bandwith and free graphic-work from the
     
     >
     
      server, that'd be great, but I don't see any.
     
     
 As a note, sending more than 3-4 images/tile is pretty meaningless - at that
point, they will almost certainly start overwriting each other, so that only 3-4
are actually visible.

 Seperating graphics from objects is a matter of tricky definition.  As said,
the server itself knows nothing about the graphic format.  what the server knows
is:

1) what spaces are visible
2) what the order of images should be (and the rules the server use for this are
object attributes, and not really image attributes - ie, it is desirable for
monsters to be visible, so we show those.  We want to send a floor, etc)  Unless
you send all the images on a space and let the client figure this out, I think
this needs to be on the server.  Note to improve server speed, the order of the
objects themselves do not necessarily match what should be seen, so sending say
that top 5 objects is probably not what you want to do.