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

[Andreas Vogl]

First of all, I like the concept of combining multipart
images very much.

Mark W. wrote:

>
     
      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.
     
     
I second Mark's proposion here. Xbms really aren't needed anylonger,
as B&W screens have ceased to exist.
Xpms are also bad. They are not cross-platform supported and they are
a big load of extra work and -space to carry around for no good reason.
They are by no means faster or better than png, they have no advantage
except maybe their visual size 24x24 in some very special cases (limited
screen?). As Mark suggested, it seems much wiser to allow scaling,
and maybe better customizable arrangement of the client's windows.

>
     
      Objects/images need to get redone. [...]
     
     >
     
     
     >
     
      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). [...]
     
     
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.

About Yann C. comment regarding graphics:

>
     
      The problem with the current architecture is that the GFX handling
     
     >
     
      has never been clearly separated from the server core. This of
     
     >
     
      course has some advantages. But it also has some major drawbacks
     
     >
     
      (basically, the current system makes the GFX too dependent of the
     
     >
     
      internal object structures).
     
     >
     
     
     >
     
      Why don't we make the GFX handling independent of the "game internals" ? 
     
     >
     
      Basically, all the client would need to know is the position of each
     
     >
     
      object displayed, the size and the associated picture.
     
     
CF being tilebased, graphics are indeed tied very closely to the objects
- and objects are *everything*. Basically I agree that graphics should
be client sided, but where does the graphic stuff end and the object-
processing start? - Hard to tell, IMO.

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.


Andreas V.