Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Changes request
Home

Re: [Freeciv-Dev] Changes request

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jules Bean <jmlb2@xxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Changes request
From: hop@xxxxxxxxxxxxxxxxx
Date: Tue, 13 Jul 1999 19:02:05 -0500

At 11:05 PM 7/13/99 +0100, you wrote:
>Artur Biesiadowski wrote:
>> 
>> Hi, I'm thinking seriously about creating java client for freeciv. I
>> will not do serious coding within month, but after that I would like to
>> spend some time on this. I have some questions/requests that would help
>> creating port tremedously and at the same time could make freeciv
>> maintance easier.
>> 
>> I could do some of this things, but I do not know freeciv internals well
>> and I have limited possibility of testing. I suppose that for somebody
>> with deep knowledge of freeciv they will be a lot easier to implement.
>
>Disclaimer: I'm not in any way affiliated with freeciv - I have browsed
>the code, that's all.  Nonetheless, I'll give my responses.
>
>> 
>> 1) Externalize all data that is possible. One sure thing are citynames
>> for races, maybe there are others. Just move them to text files similar
>> to other things in data dir.
>> BTW There is a very strange thing in units.rules with special abilities.
>> Types of special abilities first are given in hardcoded order and later
>> given to units. I think that it is better to hardcode strings for
>> special abilities in program and add name/enum lookup table.
>
>This is certainly a good idea, straightforwardly from a software
>engineering point of view.
>
>> 3) Image data. Xpm is not very good format (as it is noted in some doc)
>> and other format should be used. Plain RGBA (either 5-5-5-1 or 8-8-8-8)
>> seems reasonable to me.
>
>PNG seems good to me.  It's an open, free format which offers lossless
>compression.  Free code exists to read it in C, and I imagine Java.

-- snip snip --

Just remember, that Xpm has built-in capability for making transparent
pixels so your images can be non-rectangular in shape. If you don't have
built-in support for transparent images, it plain sucks doing it the hard
way. And by the hard way, you have to build a bitmask that tells which
pixels should be drawn, then bitwise AND the bitmask with the current
display, then XOR'ing the resulting image with the icon you want to draw.
Using a format with built-in support for transparent pixels is very
nice because then you don't have to use customized drawing routines,
just xpm library calls.

I don't think PNG can have transparent pixels. I hope I'm mistaken.
If PNG doesn't support transparent pixels, then you'll have to use
another format that does use transparent pixels, or roll your own
parser for the XPM format (whee!).

Justin Hopkins



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