[Freeciv-Dev] Re: Graphic resource editor, and an architecture proposal
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Eric S. Raymond wrote:
Jason Dorje Short <vze49r5w@xxxxxxxxxxx>:
Technically the use of a multi-sprite array is completely optional. You
can always add a new graphics file for each sprite you use. But you
will still have to set up a specfile for that graphics file and this
specfile will have to specify the dimensions of the array (even though
it has just one sprite in it).
I've already explained why I think this design is broken. You are
confirming my objections -- you're essentially telling me that specfiles
are redundant and useless, and can be replaces by a clean subdirectory
structure.
The specfile does give some useful features, for instance allowing an
author to be given for the file. Many graphics files also provide this
information via text embedded into the graphics file itself, but as
authors change the file this information is hard to keep updated.
One thing to keep in mind here is that we desire to keep
backward-compatability with old tilesets.
My editor solves that problem. The -x option takes an old-format
specfile/graphics set and bursts it into an equivalent directory.
This isn't quite the same as backward-compatability, I think - it just
provides an easy upgrade path for tileset maintainers.
In an ideal world, the system would be both forward- and
backward-compatible. That is, new tilesets could still be loaded using
the "old" civclient, and old tilesets could be loaded using the "new"
civclient. But this is a lot to ask, which is why we have manditory
capabilities :-).
Allowing sprites to be more easily placed into a single file is a
simplee matter of introducing good defaults if the [grid] part of the
specfile is not specified. The specfile itself will have to be there -
but that's probably a good thing since it does specify things like the
author of the sprite.
The right way to handle that is by putting an 'artists' metadata file
in the new-format sprite directories. Indeed, I now think that the
specfiles for graphics can be eliminated *entirely*. Not only that, but
doing so will significantly simplify the initialization code.
Possibly.
The current system of labeling artists only works particularly well when
each file is authored entirely by one group (one or more people who
share credit). When another person comes along and changes those
graphics, you can add a note about it (I suppose). But when another
person comes along and adds a new sprite to an already-existing file,
the question of assigning credit becomes tricky.
Having a history file for each sprite (giving the original author and
any contributors) is one option. But there are a lot of sprites, so
this could quickly become unmanageable. The whole thing could be done
by a single metadata file, but I'm not sure what the format should be.
Currently civclient doesn't do anything with the artists' names AFAIK.
But it is conceivable they could be automatically mentioned in the help
somewhere.
But I don't know how much extra space will be consumed when the sprite
grids are broken up. Historically I believe this is why grids were used
in the first place, but I suspect with modern graphics formats it is not
an issue.
Disk space is cheap. Consuming a bit more to simplify code and gain
flexibility is a good trade.
It depends on how much "a bit" is. Does anyone know?
But it does introduce a major problem: either each tileset includes its
own set of flags, in which case a new nation's flag must be ported to
all tilesets, or they all share a set of flags, in which case all flags
must be the same size. It does not allow any sort of query like "give
me a sprite for a flag for the Russian nation, preferably 30x30,
preferably Engels-style". This query would allow the advantages of both
systems (with some degredation in graphics quality when the "best"
sprite wasn't available).
This is the non-orthogonality I noticed and proposed to address with my
second change, the larger one.
It is larger, yes.
Do you intend to implement these both at the same time? Or to see step
1 through, then begin step 2?
My understanding is that step 1 only addresses the problems with editing
the tileset by removing the grid arrays and extraneous specfile cruft.
Step 2 actually aims to improve the data system by allowing a more
flexible indexing system. Correct?
Remember, some of this information comes from the ruleset and some is
specified by the client.
I understand. But untangling that is separate from the benefits of step 1,
getting rid of the graphics specfiles.
Entirely, yes.
Generally, the information we get from the ruleset is required, while
what the client wants is optional. In your system, the ruleset tells us
role and type, while the client (through the tileset) specifies size and
style. Getting the wrong size may be a fatal problem in some cases
(terrain), a bad problem in others (units), and no problem in others
(flags). Getting the wrong style can be ignored.
Right. All this is implicit.
Perhaps, but the design of the system needs to take it into account. It
may be as simple as returning how "close" the match for the sprite is,
and letting the caller decide what to do about it. But when iso-sprites
are taken into account (see below), it seems a lot less simple.
One thing you don't consider is that in many cases iso and non-iso
sprites are not interchangable. So in some cases (but not all!) "view"
should be a part of the tuple.
I think that should be encoded into the style as it is now ("trident"
vs. "isotrident").
I disagree.
For one thing, trident and isotrident use the same style. In fact, many
of their sprites may be identical. Allowing overlap in this case is a
good thing.
For another, the style should IMO be just a preference, whereas in many
cases getting the right view is manditory. If a lookup is done and the
requested sprite doesn't exist in that style, we want to just grab a
different style sprite and use that instead. But if this other sprite
uses a different view that may be wrong.
Note, with view just as with size how close a match we need depends on
the type of sprite. For a primary terrain sprite we need view and size
to match. For an overlay sprite (such as a secondary terrain type or
city sprite) we generally need the view to match, and the size should be
*no larger* than the requested size. For a unit, the view doesn't
matter much but the size should be matched as closely as possible. For
a flag, neither matters. (All of this is just my guess, but the
specifics shouldn't really matter as far as the design is concerned. My
point is that the query may need to allow a lot of options for "best
results".)
Note all of this is part of "step 2", and needn't be a concern quite yet.
(b) to nuke all the coordinates and tile sizes and other useless cruft
in the specfiles,
Actually, in some cases this allows things to work that otherwise
wouldn't. For instance you can take the graphics files out of civ2,
introduce the right set of specfiles, and have them work out-of-the-box
with freeciv. (There is a script to automate this process.)
OK, granted this is desirable. But we shouldn't let civ2's design
constrain our data design. Instead, the right answer would be to have
the conversion script call my tool for unpacking the civ2 specfile
format.
Indeed.
Another advantage of the specfile is that you can use the same sprites
in a different way, although I can't see an example of this in use. So
I guess this is a bad example :-).
jason
|
|
