[Freeciv-Dev] Re: Graphic resource editor, and an architecture proposal

["Eric S. Raymond" <esr@xxxxxxxxxxx>]

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.
 
> 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.
 
> 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.

> 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.

> >2. The bigger problem is that the ownership of data is in many cases
> >unclear.  Nations sort of own flags, but not really because flags vary
> >in size by tileset.  Some tilesets share flags (by size).  Every
> >tileset uses the same shields file.  There are funky crosslinks
> >everywhere.  You can't change any one thing without breaking
> >everything.
> 
> Indeed, and this relates to the ruleset<->tileset interconnectedness I 
> mentioned above.

That interconnectedness needs to be addressed at the design layer, then.
But the change I am advocating at least peels away one layer of
complexity.

> The idea is that each tileset specifies its f.russian flag.  The fact 
> that all tilesets use the same set a flag is just because of the 
> laziness of tileset authors (whether you consider this a good or a bad 
> thing is another issue).

Right, I know that the actual flag names are indirected through the nation
files.  The *nation* actually specifies the flag name; the client looks up the
spritename specified in the flag slot.
 
> 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.
 
> 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.
 
> 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.
 
> 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").

> Well, the fact that they're in the misc/ directory should indicate no 
> _specific_ tileset owns that sprite.  But it is a fact that most sprites 
> (not just flags and shields) are ruleset-dependent (although I don't 
> know who "pretends" otherwise).

The "pretense" is implicit in the inclusion structure. :-)
 
> >(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.
 
> >(c) to abstract the lookup so we can do clever things like
> >automatically fetching a best-fit image when the size hint doesn't
> >match what we have available.
> 
> Yes, this is a big benefit.

I'm glad you agree.
-- 
                <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>