[Freeciv-Dev] Re: Heads-up -- bunch of cvs adds coming up

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

Jason Dorje Short <vze49r5w@xxxxxxxxxxx>:
> From a private conversation...
> For me the editing concern is secondary.  If we have good editing tools, 
> it should not be important for editors what form the data is in.
> 
> These editing tools can also do things like make sure the tilesets are 
> in paletted PNG form with a nice palette (or something different, if it 
> becomes desirable).
> 
> A primary goal should therefore be to develop such tools.

I've already written one.  PIL makes this sort of thing really easy.
 
> Now, this is a concern.  If the 300 (?) tiles we have now take up 6 
> megabytes on a 4k-block filesystem, I suspect a 1500-tile tileset will 
> be rather large.  (The fact that it is 128x64 with many colors probably 
> isn't as significant at this point.)

We'll make a lot of this back.  There are many duplicate sprites,
as it turns out.  And many, *many* pairs that differ only by
transparent padding.  Ultimately, my goal is for there to be only one
copy of the tx.village sprite (for example) that is used by every
tileset.  The offset from the draw point, which is now expressed by
different transparent padding around various copies ofthe icon, is
really a per-*tileset* property and should move into the tileset
declarations.

But fixing that will be part of the stage 2 reorganization.

> For: easier and faster to load sprites since no clipping is required
> Against: sprites are larger and slower to load
> 
> Again, these mostly balance out - we're only talking about a few lines 
> of code in tilespec.c, and the load times seem about equal.

Agreed.

> For: slightly easier/faster to load sprites on demand
> ...but only slightly easier.  Rafal has pointed out that using the 
> current system with load-on-demand, we can cache the most recent "big" 
> sprite that we loaded.  Almost all of the time this will result in 
> near-perfect caching.

Good point.  This is only a very marginal advantage for my proposal.
 
> Against: a HUGE number of files in CVS.
> ...we're not just talking about difficult for tileset authors, but 
> difficult for anyone who tries to maintain any tileset packages.  The 
> Makefile.am alone will be tremendous.
> 
> Against: large size of data on disk
> ...this is frighteningly large, but then again disk space is cheap and 
> good filesystems are even cheaper.
> 
> but all of these are minor, modular issues: again a push IMO.

Agreed.  Though a lot of the file proliferation will go away at stage 2.
My best guess is that the number of independent sprites could be cut by 
a bit less than half relative to the current naive conversion.

> However, there is an overriding issue: the step 2 data reorganization. 
> This is, in concept, a very good idea IMO.  But without flushing it out 
> more I don't know what direction it is going to go: whether a 
> single-file-single-sprite+graphics-path-determines-name or a 
> sprites-go-anywhere+names-are-in-a-database method will end up being 
> better.  So perhaps we should start discussing this again?
> 
> Eric, you're obviously in favor of splitting up the PNG files.  But you 
> need to give us reasons why this is better.

Hm.  Where do I start?

With esthetics, I think.  The present design is so ugly and
over-complicated that it makes my teeth hurt.  I want to shoot it
through the head and put it out of my misery.  How ugly is it?  Let me
count the ways:

1. Every single number in the current graphics specfile format --
x_top_left, y_top_left, dx, dy, is_pixel_border, and all the
coordinate pairs -- is implementation cruft having *nothing* to do
with the actual job of rendering the tile.  I find that offensive.

2. Tilesets duplicate the hell out of a lot of common icons.
This is wasteful of machine resources (which doesn't matter)
and of human bandwidth (which does). It's hard for people thinking
about improving the tilesets to grok the relationships between them,
and hard for artists to be properly credited.

3. Overlay variants use transparent padding to control where the
payload will get dropped on a tile.  This makes them brittle, both
with respect to the tileset's cell size and each other.

4. Because tile arrays are big lumps of binary data, merging in
incremental changes is hard.  The 12-nations patch is a perfect example
of the problems this causes.  I have his flags only as diffs to 
an XPM.  To have any chance of recovering them, I'll have to figure
out what the version of his XPM has, retrieve it, apply patch(1)
and hope the result isn't garbage.

These are symptoms.  Now let's look one level deeper:

A. All the graphics specfile syntax is, is a stuff is an elaborate,
clanking set of machinery for implementing name lookup into a tile
array.  It's a complicated kluge to implement what should be a 
simple name-to-sprite mapping.

B. In the sprites, information about the sprite's role and meaning (the
actual pixel bits) is mixed with information about a tileset's rendering 
tactics (the padding).

I guess you guys have been living with this design too long; you don't
see how bad it is.  But it drives me crazy.  Here's how it *should* look.

A database implements a mapping from (role, tileset) to 
(spritename, xoff, yoff),  The xoff/yoff is an offset relative to the
upper left-hand corner of the tile's base cell.

Later on, in stage 2, the mapping should change so the mapping is
is (role, style, size) -> (spritename, xoff, yoff).  The tileset
name should become a style hint.

My use of sprite directories is just a way to get fast (role, tilespec)
lookup in a transparent way. It's better than a binary database when
performance is not a pressing issue -- and for our purposes maybe
better even when it is.

The new design is better because it's clean.  It gets rid of all the
pointless, bogus magic numbers.  It will allow me to properly separate 
per-tileset information from per-spritename information, which will
be essential for intelligent lookup later on.  And, as a nice site
effect, it will eliminate duplication of sprites.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>