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

[Mark Wedel]

On Tue, 4 Sep 2001, Yann Chachkoff wrote:
>
     
      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.
     
     
 Some would argue that xbm's are still useful if playing on a black and
white system.  But at some point, we have to say that is not supported.

 XPM's are smaller in dimensions (24x24) but not actual file size.

 The reasons to get rid of XPM's:
1) When making new arch's, don't need to make an xpm image (this could be a
   minor point if an automated tool is used to convert a 32x32 image to 24x24,
   but the results look pretty crappy, and I think after that happens for a
   while, people won't be happy with the xpm's anymore)
2) Save space.
3) Eliminate a bunch of code (can remove all xpm related code from client and
   editor, and only need png code at that point, which then means less work)

 In terms of display size, if this is an important consideration, I would
rather add scaling of the png images in the client (if you do a half size
reduction, the results should be somewhat decent).  In a very long run, the
results of this may be the same as keeping an xpm set that just scaled
down images (down by program, not by human).  Scaling also gives even more
options - you could have 75% scaling, or 50% scaling, or whatever else.

>
     
      >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
     
     >
     
      ?
     
     
 I should note when I said 'I'd only do the gtk client', I meant that
literally, in that the only one I would personally update is the gtk client.
The java editor should be updated, as probably should the directx client, and
potentially any/all of the others.  DirectX is closed source, so only one
person to my knowledge has access and can update that (MT).

SDL client and iso?  It depends how they were written - it is possible they
were written in anticipation of variable sized images, so they may no in fact
need any work to handle tall images.

Crossedit is iffy.  I personally still find it more usable than the java
editor - largely in terms of speed and reliability (I think that later may
be an issue with the jvm and not the java editor itself).  But at the same
time, it doesn't make a lot of sense to spend time on something that may/should
go away.  And if a native editor is really desired, then making an SDL or gtk editor
or something would probably be the way to go, but that seems like a lot of wasted
work when there is the java editor.

 More options is never bad, but when there are limited resources, it seems much
better to me to focus on a few things and make them good instead of focusing o
half a dozen things, all of them so so or not fully complete.


>
     
      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).
     
     
 The change described would remove that to some extend, as big objects
would just have one big image.


>
     
      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.
     
     
 At some level, the two have to agree.  If there is say a big monster
but its tiles don't correspond to what it looks like, the player may
have a much more difficult time attacking it (trying to find the tiles
the monster actually is on, but due to the graphic it doesn't appear on
that tile, or finding out that a big monster (in terms of tiles) has
a smaller face, and the monster is effectively next to the player and
bashing him to pieces even though it shouldn't be).

 In the revised system described here, the client would know the size
by looking at the image data.

>
     
     
     >
     
      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.
     
     
 I'm not sure what you are really asking that is different.

 Currently, when the map is sent to the client, what is contained there
is the image information (sent as numbers, but prior that name for
each number is sent - sending numbers is just more efficient), and its
location on the map.  This revision would not change it.

 Seperate picture servers have been discussed before - there is nothing
inherently wrong about them.  But the basic fact is that if the client
needs an image (for a new arch that has been added lets say), it needs
a 100% reliable way to get it - and that best way to do that is to make
sure the server can provide it (if the server is down, your not playing
anyways).

 Now you could still have image servers which is the first choice for
new data, and then fall back to the local server in cases where the
image server is down or may not have the image (lets say it is really
new or a customization only on one server).

 I should note that the server itself knows nothing about the images - to
it, they are just a bunch of bits.  And the code that handles the reading
and sending of these bits is actually pretty basic and doesn't have a lot
too it, so removing that from the server doesn't gain a lot.  I could
certainly see the point of having image servers so some could be
isomorphic and others top down and you can then just get whatever one
you want depending on your playing style.