Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2000:
[Freeciv-Dev] Re: alpha patch to provide wonder creation eye-candy
Home

[Freeciv-Dev] Re: alpha patch to provide wonder creation eye-candy

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: John Heidemann <johnh@xxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: alpha patch to provide wonder creation eye-candy
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Thu, 28 Dec 2000 11:23:45 -0500

At 2000/12/10 23:10 , John Heidemann wrote:
>>Attached is an alpha-quality patch to provide wonder creation
>>eye-candy (the PR I submitted last weekend).  The patch is against the
>>current CVS archive.  To use this you need to apply it and rebuild
>>both the client and the server, and get some sample graphics from
>><http://www.isi.edu/~johnh/PUBLIC/build.tar.gz> (extract them into the
>>new directory misc/build).  Then, when you build a wonder that has a
>>corresponding graphic a window will pop up with the special graphic.
>>
>>This patch is preliminary in a few ways:

The patch I retrieved didn't actually compile, so I just sort of read it...

>>1. Probably the graphic filenames should be defined in the
>>buildings.ruleset, or at least the path where the graphics live should
>>be specified in a .spec somewhere.  Advice about what/where?
>>(Currently the filenames are just numbers
>>and the directory is hardcoded to misc/build.)

Yes.  These new graphics are much like the "intro" graphics, in that they
are loaded and unloaded as needed.  The "intro" graphics are currently done
as a kind of special case.  It would be nice if both "wonder" graphics and
"intro" graphics would use the same (or a similar) mechanism.

Also, that mechanism should be implemented as much as possible in common
code.  The current patch exposed a low-level routine, then did most of the
work in client-specific code.  Instead, it should have extended the
tilespec API, added most of the code in client-common, and then performed
minimal work in each client.

The actual file names should be defined in a .spec file, and that .spec
file referenced by some .tilespec file.  And, the tags used to link the
buildings to the graphics should be specified in the .ruleset file.  See
"~/data/trident.tilespec", "~/data/trident/units.spec" and
"~/data/default/units.ruleset" for an example of the general structure.
Also, see "~/README.graphics" for an explanation of the tilespec system.

I don't off-hand know where best to put these graphics and spec files.
Perhaps "~/data/build"?

>>3. I didn't look at any backends other than gtk.

We'll need at least Xaw, but that should be straight-forward (if most of
the code is common).

>>4. Other things?

Using the wonder's ID as the file name seems too rigid -- rulesets could
change this.  A descriptive file name plus a .spec file to do the mapping
seems much better (see above).

Probably shouldn't add B_FIRST_WONDER and B_LAST_WONDER -- all the B_
constants are slated to be removed in the (hopefully) near future when
"generalized improvements" is implemented.  Also, why limit graphics to
wonders?  Let the .spec file decide what exists -- maybe someone would want
to see a picture of every Phalanx unit built...

... Well, probably not.  Which reminds me of control.  Just looking at the
patch, I couldn't tell if the player could turn off this feature.  I think
it should be optional.  And, perhaps, optional by kind of thing built
(unit, improvement, wonder).

jjm




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