[Freeciv-Dev] Splitting the tileset PNGs
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Eric S. Raymond wrote:
Jason Dorje Short <vze49r5w@xxxxxxxxxxx>:
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.
I don't see how you can possibly fix this using data reorganization.
This has everything to do with changing the low-level drawing code
(tilespec.c and gui-xxx/mapview.c) to be able to handle non-0-offset
draws without the "special-case" currently used by coasts.
And this can be done just as easily with or without having the PNG files
split.
Perhaps I am missing something?
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?
Let's focus on *how* splitting the PNGs will help, not on the side
benefits (which are not really dependent on splitting the PNGs).
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.
Indeed. Perhaps the solution is to redesign the data access method so
the specfiles are not used?
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.
As I said above, this has nothing to do with having the sprites grouped
into large PNGs.
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.
Same as above.
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.
Good point; ouch.
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.
Yes. But I have't yet seen how the split-PNG system implements this.
In the file graphics/trident/unit/awacs.png, how is the lookup done?
How is this better than having the same information in a specfile?
Once the extra pixel border is not necessary and tx.village is the same
between trident and isotrident, additional information will be needed to
tell the drawing code where to render the sprite. This information will
be the (x,y) offset from the tile origin. For instance if we crop a
64x32 sprite down to a *centered* 20x20 sprite, the drawing code could
just center it. But most graphics are not centered, and to require
transparent padding to center them is an even bigger hack. So we need a
way to tell the drawing code to offset the sprite by (22,3) (for instance).
Doesn't this require more specfiles? If we're going to have specfiles,
isn't it easier to have them in small groups - like the current
specfiles, but streamlined? Or alternately: how do you think this could
be handled in the split-PNG system?
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).
Yes, this is not good. But it is not easy to fix, since the parts that
need to be changed lie deep in the drawing code.
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.
OK. How is this better than mapping (role, tileset) to (spriteloc,
xoff, yoff), where spriteloc gives the sprites's position and dimensions
in a larger PNG file? You just think this is unnecessary (it is a lot
to edit)?
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.
OK.
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.
But the directories cannot be used for the (role, tilespec) lookup, can
they? Take graphics/trident/unit/u.awacs. One might think this is
(tileset, role, name) = (trident, unit, u.awacs). But what about all
the shared files? How does a tileset specify using them (or *not* using
them)?
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.
Hmm, I am still not convinced (although getting closer; #4 is a symptom
of the general problem of having everything stuffed together and I am
wondering what other symptoms there are).
I remember having a Mac with a 64-k blocksize on the file system once.
On that system, the 1454 sprite files would take up 93 megabytes of
space. But we're not going to worry about the extra space :-).
jason
|
|
