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

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

Jason Dorje Short <vze49r5w@xxxxxxxxxxx>:
> 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 :-).

Backward compatibility is all very well, but when it gets in the way
of a design cleanup *and* (essential!) there are good tools for
forward migration, I say backward compatibility can go hang.

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

I've already upgraded my editor/converter to do this.
 
> 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.

Indeed it does.  But this is orthogonal to the representation issue.
Right now you have just one lump of data that represents attributions.
The artists file is one lump of data.  No change.

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

Why tangle the question of what the one lump of data ought to look
like with the higher-level reorganization?  Let's worry about what the
artists file ought to look like *after* the larger problems
independent of it have been solved.
 
> >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?

I could gather some statistics, I suppose.
 
> Do you intend to implement these both at the same time?  Or to see step 
> 1 through, then begin step 2?

Step 1 first, but in a way that prepares for step 2.  

I'm adding a mode to my editor/converter that mass-converts an entire
data directory to the new format.  Then I'll change the handful of lines
of code needed to make the new lookup work.  Patch 1 will consist of
those changes and instructions on how to run the converter.

The preparation for step 2 will consist of the detail that all graphics 
will live under a single top-level directory, data/graphics.  However
I won't try to change the naming conventions for sprites -- that will
be necessary in step 2 but is avoidable in step 1.
 
> 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?

Yes, precisely correct.  I know *exactly* how the first-stage redesign
should go.  It's a fast, easy change.  The second stage will take
more time and thought.  It has implications that will reach further
into the code.

Actually I don't want to implement stage 2 alone.  It's going to take
knowledge of the client code that I'm not very interested in
acquiring.  I'll learn that if I have to, but I'd be happier concentrating
on data design and infrastructure.  My preference would be to team with
one of the client-side experts, if I can get one interested.

What I shall dangle in front of that wizard :-) is the prospect of 
intelligent lookup, so that the client can do a best-fit analysis based
on deductions about the user's environment and higher-level hints.  Like:
"X tells me his screen DPI is 120dpi.  He says he likes Engels style.
What's the best I can do for him?"

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

You raise good points here.  You sound like one of the right people to be
working with on a smart selection algorithm, once things get to that
stage.

You have affected my thinking in one respect.  I think the Stage 2 data
design is going to have to be flexible enough that we can add more
attributes to indexing tuples without having to re-code a lot of stuff.  
This isn't going to be easy in C.  *Sigh*.
 
> Note all of this is part of "step 2", and needn't be a concern quite yet.

Yes.  And a good thing, too.

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

Not *completely* bad.  There's one pair of aliases in the default flags file
that has to be expressed as two duplicate icons in the new system.  I
considered converting this to a hard link, but those aren't portable
off Unix.
-- 
                <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>