Complete.Org: Mailing Lists: Archives: freeciv-dev: August 1999:
[Freeciv-Dev] Re: Suggestion concerning tile specs
Home

[Freeciv-Dev] Re: Suggestion concerning tile specs

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx, David Pfitzner <dwp@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Suggestion concerning tile specs
From: sebauer@xxxxxxxxxxx (Sebastian Bauer)
Date: Tue, 31 Aug 1999 20:02:54 +0100

Hello David

[Remove the gfx format extension in the spec files]
> One consideration is that you could at some point
> have tiles.xpm and tiles.png which have _different_
> spec files (eg, someone added a few tiles to one but
> not yet to the other).  Though maybe thats a raw case,
> but I thought it was safer this way (and not too
> much trouble to copy the spec files and changes a
> few lines?)

That's would be no problem, I think. See below.
(I hope I understood everything correctly ;-) )

> Also note that in principle you might want multiple
> spec files for a single xpm, which is why I didn't
> just have the spec/xpm files related implicitly by
> filenames.  

Then the user can/must create a new .tilespec file anywhy.

>> E.g. tiles.xpm.spec should be renamed to tiles.spec.
>> Inside the specfile itself the gfx file should be
>> referenced without any extension e.g.
>>  xpm = "default/tiles"
> But if its not really an xpm file, that should be
> somethings else rather than "xpm =" ?

Yes, of course ;-)
Maybe something like gfx ;-)

> I was thinking new graphics formats would use
> eg, "png = " in the spec file, but if you want the
> same spec file to work for different formats thats
> not so good.  Well, you could allow the spec file
> to contain both "xpm = " and "png = " but you still
> have to modify the spec file if you want to add more.

My idea is it that the client decide which format
to use. As I read the Mac client will use the pict
format so we would have to add a new entry for it,
too. The problem is that the tilespec is read
within the gui independ part of the client (which
is of course very good).

> I guess its a tradeoff between convenience (letting
> the user change the graphics format without modifying
> the spec files) and generality (allowing multiple
> files with different extensions be different and thus
> have different spec files).  

I really think that the first way ist the best. I also
don't see that is less general than the second way.
The user still can have different gfx file extensions
(this depends anywhy on the client; which formats it supports) 
and so different spec files. The only restriction would
be that he/she cannot have these differnt gfx files in the same
directory. I don't think that this is a problem because
if the gfx files really are differnt then it is better
to do them in different directories as well ;-)
(hu...much differents, I hope you understand what I mean ;-) ) 

Also the first way has the adventage that you needn't
to care in the cvs for the fileformat and you still
can let the xpm gfx files inside (because both the xaw
and the gtk understand this format) which is probably better
than a binary format?
Which gfx format is really used in the distribution archive
can be choosen by the creator of the archive. If the
client can read only xpm he have of course no choice and
can only incude the xpm files. But if the client understands
additionally e.g. a png format he can convert the xpms to
pngs and include them instead.

>> Then we can create a new gui depend function which
>> simply returns the gfx file extension the client
>> supports (maybe it could even return a string array,
>> which defines all the extensions the client supports;
>> if the first file with the first extension isn't found
>> the second extension is tried...and so on).
>> This function is used somewhere in tilespec_load_one()
>> then.
>> What do you think?
> Yeah, something like that is probably good.

Ok. I will write the patch for this. But at first we should 
finish the tech patch and I still hope that my paratroopers
patch will be integrated ;-)

bye,
Sebastian Bauer


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