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

[Yann Chachkoff]

At 03:28 05/09/01 +0200, you wrote:
>
     
     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.
     
     I agree with the idea of suppressing the XPMs if the PNG can be scaled 
down. The only problem I saw with PNG was their size. Removing XPMs will 
definitely simplify the code and the GFX-makers work.

>
     
     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.
     
     I simply do not understand the direct relation between the visual aspect of 
the game and the internal representation of objects. I agree that each 
object should have one or more associated pictures; I also understand that 
some "line-of-sight" calculations needs to be done by the server (for 
example, "what part of a monster can you see by looking at that door ?"). 
But I maintain it: the object handling (movement, size, coordinates, 
events, etc.) and the graphical handling (the way pictures are sent and 
displayed) are completely different things, even for tilebased games like 
CF. That's because it is not true _now_ that I suggested some thinking 
about improving that situation.

>
     
     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 am not sure of that. In reality, what the server has to decide is what 
_objects_ should be displayed, and in what order IMO.

>
     
     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.
     
     I doubt that letting the client handle the graphics would result in lagging 
it; I never suggested an increase of the data transfers between the server 
and the client, quite the contrary ! And I do not see why letting the 
client handle the graphics would result in an increase of that traffic.

>
     
     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.
     
     That's why such mailing lists do exist - to share ideas. Maybe of course 
I'm completely wrong with all this (who said "again" ?), but at least I 
expressed my opinion so anyone can think a little about the idea.

Chachkoff Y.