Re: [Freeciv-Dev] Graphics file format

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxxxxxxxxx>]

On Mon, 26 Jul 1999, David Pfitzner wrote:

> On Mon, 19 Jul 1999 David Pfitzner wrote:
> 
> The consensus seems to be to use PNG.  I gather that for the Gtk+ 
> client, changing to use PNG would be quite easy.  (At least if we 
> assume the user's Imlib contains PNG support compiled in?)
>
> For the Xaw client, it seems we have a few options:
> 1. Require the user have some appropriate library to handle PNG
>    (presumably instead of current libXpm requirement).
> 2. Include code in freeciv to directly support PNG (presumably
>    scavanged from some other GPL'd source).
> 3. Leave the Xaw client using xpm graphics. 
> 
> Option 1 means freeciv may not work 'out-of-the-box' on some 
> systems where is does now.  How palatable this would be would 
> depend on exactly which libs we would require and their portability
> etc, which I'm not sure of myself.  

This means you should use something like ImLib i.e.:

You require:
Imlib
libpng
libz

Why libz do you ask?  Because libpng depends on libz to handle PNG
compression/decompression routines. :-(

> Option 2 is a bit ugly since this does seem to be something
> a library should do.  Would depend on how much code is involved.

The problem is that unlike libXpm which includes functions to convert a
Xpm into a XPixmap libpng doesn't have any X support.  It limits itself to
handling the necessary conversions so you can access the Pixmap data
as an RGBA array.  You still need functions which can convert this into a
XPixmap.  This means you also require functions which do color 
quantization (ala libXpm) or dithering (ala ImLib) unless you assume all
users have a screen display with at least the same number of free colors
as the Pixmap's color pallete. Fortunately libpng is extremely  portable
(i think it only requires an ANSI C compiler unlike libXpm which is more
demanding).  But don't forget that libpng also requires libz...

> I would not be too unhappy with option 3, at least in the short 
> term, or perhaps as a configure option if configure doesn't find 
> appropriate libs for PNG support.  If we did this, I think it 
> would be ok to include one 30x30 xpm tileset in the distribution, 
> as well as whatever png files we include.  Plus more tilesets in 
> both format on the website.  The thing here is that its easy for 
> us to convert from full-color png 'source' files to low-color 
> xpm files, but not the other way. 

Xpm is a bad graphics format for anything bigger than a bunch of icons.
The parsing of Xpm files is way slow. And for 24-bit graphics Xpm files
get too big.

IMHO the best option would be to use something like the TGA graphics
format (the AlphaCentauri folks use PCX which is very similar).  This
format has 24-bit, 16-bit, 8-bit support with a full alpha channel and RLE
compression.  I know it doesn't compress as well as PNG but since it is a
simple format it would be easier to add support for it in the client.

---
Vasco Alexandre da Silva Costa, student @ Instituto Superior Tecnico,
Technical University of Lisbon - Software & Computer Engineering