Complete.Org: Mailing Lists: Archives: freeciv-dev: May 1999:
Re: [Freeciv-Dev] Small patch :o)
Home

Re: [Freeciv-Dev] Small patch :o)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: a_beraud@xxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Small patch :o)
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Wed, 19 May 1999 22:38:06 +1000 (EST)

Alexandre BERAUD wrote:

> Once again, I think the solution would be a 256 colors
> default tileset ! When commercial games display millions
> of colors, Freeciv hardly displays 64. Don't tell me nobody
> can have at least 256 colors now.

Two main factors I can think of for using 64-colour 
palettes instead of 256:

- Increasing the number of colours much over 64 doubles
the size of the xpm files.  Those files already make up 
a large fraction of the distribution size.

- 256 colour displays means 256 colours in total, 
which means you don't get to use 256 just for small.xpm
Even if one makes sure all of the xpm files use the
same palette, there are also a few other colours used
by widgets and inside the code.  (And the user may have 
other applications than freeciv which also use colours,
unless one uses a separate colormap.)

I think the first problem above can actually be overcome 
to a large extent of one uses 64 color palettes, but 
individually optimised for each file (so small.xpm would 
get 64 colours optimised just for that file, which I've 
tried and think looks reasonable).  This assumes that one 
ignores the second problem (eg, assume 16 bit colour or 
better, or live with whatever happesn on 8 bit displays).
This is what I did for my "dwp favourites" tileset, which 
will certainly now include Alex's new small.xpm :-)

The above is not to say that freeciv can never has 
graphics with lots of colours, just that there are some 
reasons for choosing 64 instead of 256 with the current 
implementation.

Regards,
-- David

[Prev in Thread] Current Thread [Next in Thread]