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

[Yann Chachkoff]

>
     
     ===== Original Message From Mark Wedel <
      
      mwedel at scruz.net
      
      > =====
     
     >
     
      I finally have some time to think about doing this, so I thought I would run
     
     >
     
     over the ideas/thoughts to the list.
     
     >
     
     
     >
     
     Background:  currently, big monsters/buildings (say the shops) that are more
     
     >
     
     than one space are made up of multiple images.  The shop for example is 
     
     actually
>
     
     4 images, and not one.  The proposal is to made the shop just one image of 
     
     64x64
>
     
     in size (for purpose of this e-mail, I am going to use the current 32x32 tile
     
     >
     
     size and not other tile sizes).
     
     <snip>
I agree with the general idea.

>
     
      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.
     
     >
     
     
     mmm. There I'm not quite sure, so I extend myself a bit.
I agree that XBMs are not used a lot these days - they are quite ugly and do 
not offer any advantages over XPMs or PNGs IMO.
I disagree with the fact that XPMs should go. XPMs are smaller than PNGs, and 
thus easier to display on quite a lot of machines. That may be only a small 
argument for maintaining XPMs, but it is definitely worth to think about it.
I do not see why it would be a pain to try to support combining XPMs into 
larger images.

>
     
     To my knowledge, this currently includes the java client
     
     >
     
     (unsupported/unmaintained?), direct x client,
     
     >
     
     native sdl client, gnome client, gtk client, x11 client, java editor, and
     
     >
     
     crossedit (near unsupported). Certainly not all those need to get updated, 
     
     but
>
     
     I'm not sure which/how many are being used and how many people will complain 
     
     if
>
     
     their favorite program no longer works. I'd only do the gtk client for sure -
     
     >
     
     any of the others would be much more up in the air.
     
     
Again, I disagree.
I admit that Crossfire was initially a UNIX game, making the X11 (and later 
the GTK) the "standard" client. But today, the DirectX one is quite commonly 
used, so you certainly need to add it to the "must-update" list. The same is 
true for the Java Editor, which is quickly becoming the new standard. 
Crossedit could of course be removed; but remember that if doing so, it will 
mean you'll need Java to be able to create maps - crossedit may be outdated 
and ugly, but it is the only "native" editor currently available.
Another question I want to ask about the SDL client and the ISO-related stuff: 
what will be done about them ? Does it mean another complete change with them 
?

>
     
     Objects/images need to get redone.  This can be done in a piecemeal fashion
     
     <snip>
mmm. I agree that the current Objects/Images system needs to be redone.

However, I'm not quite sure that it is really a good idea to try to "recycle" 
the current system into an improved one. Of course, it may make the 
development time shorter. It also mean that we'll get the risk to end up with 
an "hybrid" system that may proove too limited again on the long run.

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.

In my own opinion (but remember that it is just a personal point of view), all 
the GFX handling should be in the hands of the client. A picture would be only 
sent from the server only if the client explicitely request it (like the 
"cache images" system currently used). Maybe the "picture server" could even 
be a completely separate program (a picture server / picture set & format for 
example). The server should only send relative positions of each visible 
object.

Again, I understand quite well that my solution would require quite a lot of 
work and an intense thinking (and lots of people want results fast). But I 
believe that solution will finally end up with a clearer and lighter 
communication protocol combined with a server less dependent of the visual 
material.

Chachkoff Y.

-----------------------------------------
Visit 
     
     http://www.chachkoff.f2s.com
     
      for
a journey into a fantastic world !
(But don't expect too much...)
-----------------------------------------