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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

From a private conversation...

The opinions of tileset authors are especially wanted.

Raimar Falke wrote:
> On Wed, Jan 29, 2003 at 06:08:58PM -0500, Eric S. Raymond wrote:
>
> > Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>:
> >
> > > Ok then do I raise this objection: while I think that the proposal
> > > make is easier to add sprites it makes the creation and change of
> > > sprites harder.
> > >
> > > Especially if we consider larger tilesets. From an older mail from
> > > Jason:
> > >
> > > 'civ1' system (currently used for non-iso tilesets): about 200 tiles
> > > 'civ2' system (currently used for iso tilesets): about 80 tiles
> > > 'civ3' system: about 1500 tiles
> > >
> > > While we have currently no support for the civ3 system there is no
> > > real problem why we shouldn't support it. So it will come at some
> > > point and I don't know how many of the graphics people know how to
> > > script their gimp to make a certain green a bit darker in all 1500
> > > files.
> > You're right; hacking Scheme is too hard for most artists.  But then,
> > at the 1500-sprite level it wouldn't be practical to put the sprites
> > in a small enough number of tile arrays to be easily palette-hacked by
> > hand, either.  So at civ3 we're going to have this problem no matter
> > which way we go.  Fortunately it's not a hard one; I could code up 
> > a mass palette-hacking tool in PIL within 20 minutes or so.
>
> > Right now, today, the most common form of modifying the graphics
> > resources is adding a sprite (especially a flag or shield).  That's
> > exactly the case that the new system will make easier.  Hacking all
> > the palettes is by comparison a rare operation.  Bit-editing of the
> > sprites is probably more common, but these can be edited in bunches
> > pretty conveniently under the new system via the GIMP plugin (I forget
> > the name) that behaves like the old Visual Schnauzer feature in xv.
>
> I disagree what the common and rare use is. Last change to
> trident/flags.xpm was 2000/09/24. The reason why no flag was added
> after this was probably that we hit the 64-nations limit. The file
> contained however at this time 81 flags. This limit was removed Thu
> Mar 21 20:35:24 2002 (GMT).
>
> In the last 6 months Daniel has create multiple tilesets
> (http://www.freeciv.org/screenshots/1.12.1/isomsets/).
>
> So from past experience I disagree.
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.

> > So: the new system makes the commonest use case much easier.  Bit editing
> > is pretty much a wash between the new and old systems. Palette hacking
> > is easier in the old system *if* the tileset is Civ2-sized -- larger
> > than that, and you're going to need power tools in either case.
>
> For civ3 based tilesets the goal is to get the infrastructure in place
> so that people can use the original civ3 tilesets or one of the
> contributed ones (there are very nice ones out there). It would be
> nice if a freeciv-related graphic artist creates/modify one but this
> isn't necessary.
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.)
This doesn't really affect the tarball size, which is also very 
important (since bandwidth is much more limited than disk space for most 
people).
-----

So my question is: aside from editing issues, what are the technical 
reasons for/against this change?

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.

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


Based on all of this I see no good reason to pick one method over the 
other.  Which would probably mean the current method stays.
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.
jason