[Freeciv-Dev] Re: Improvements in dithering

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Warning: I have a strong tendancy to ramble.

On Tue, 2002-12-03 at 23:09, Daniel L Speyer wrote:
> Hello all, sorry about my long absence.
> 
> I've been playing with improvements on dithering, and I think I've come up
> with some.  You can see a finished screenshot at
> http://dspeyer.student.umd.edu/under_dither.jpg

Very slick.

There are some brown artifacts in the hills/mountains.  What causes
these?

> The first and simplest change is the new multi-dither.  This is a pure
> tileset change and I've attatched the relevant file (it requires the
> existing multi-dither patch).  In terms of philosophy, it's a move away
> from shaped fuzziness and toward a more puzzle-piece-like structure.

When I first saw the multi-dither I was impressed.  The effect is subtle
but pervasive.  But upon further review I think we can do better with
terrain-based blending masks (along the lines of what you've done
below).  Yet I don't understand how the two work together.

> The other changes make terrain go right up to coasts hills and
> mountains.  In the present system, mountains in desert have a circle of
> grassland around them, and desert coasts have a band of neutrally colored
> terrain.  This is bad.  The solution to these is the same.

This is very nice looking.  But I think we can do even better.

I still don't entirely understand the current drawing system.  But I
spent a long time looking at a civ3 tileset, and their system is also
slick.  But it requires lots of work - over 1500 hand-drawn tiles - and
also restricts the set of possible terrain lest it need more.

I also came to the conclusion that writing the code for these graphics
would be much easier than making the graphics.  This seems to be the
trend for any new graphical system.  But as things stand now it would
basically require re-implementing it for every GUI.  So I've focused on
unifying portions of the GUI code first (note, there are also many other
reasons for doing this).

I see the drawing system in the abstract as a mostly discrete set of
options:

* isometric versus non-isometric.  Currently the isometric code is
isometric and the non-isometric code isn't.  But I suspect only a very
small amount of code depends on this difference - it is mostly taken
care of by masks.

* What adjacent terrains affect forests/hills/mountains ("comples"
terrain),  Currently non-iso considers the terrain E and W of the tile;
the iso considers N,S,E,W.  Providing code that handles all cases should
be very easy.

* Whether hills and mountains are considered equivalent for adjacency
purposes.  Currently this is a "no" for both iso and non-iso.  I believe
it should be "yes", though it looks like it will have to be made an
option.

* Whether adjacent terrain affects grassland/plains/desert/tundra/arctic
("basic" terrain).  Currently non-iso considers the N,S,E,W terrains (16
total tiles each) while the iso ignores everything.

* Whether a blending mask ("dither") is used.  Currently this is "yes"
for iso and "no" for non-iso.  Note, it is possible to introduce other
blending mask options as well.

* Whether (rail)roads are drawn as overlays or whether all 256
combinations are hand-drawn.  Currently iso and non-iso both do things
as overlays.  Civ3 hand-draws them.

* Whether the "bad corners" of rails are fixed.  Currently this is no
for both iso and non-iso.  But we should provide the option in both
cases.  If anyone can figure out a clean way to implement the civ3
system I would like to hear it.

* Whether eye candy sprites are provided.  Currently this is "no" for
both iso and non-iso.

* Whether ocean tiles are implemented in full tiles or in quarters. 
Currently non-iso uses full tiles; iso uses quarters.

* Some more options about ocean tiles.

Yet even here there is a lot of overlap, and a simpler system is
possible.  If we support quarter-tiles for ocean, why shouldn't we do so
for all basic terrain?

At this point the above modular system is a far-off goal.  But progress
is being made toward it.

Note, the use of the options above in a tileset are mostly trade-offs. 
You can get a better tileset by including more sprites.  Or you can keep
things simple and focus on having better-looking sprites.  However,
there are some options (generally those used by the current non-iso
case) that just aren't good for anyone.

> I created a set of under-dithers (probably nota a great name) which let a
> tile be divided four ways amongst its neighbors ith interesting
> borders.  I then draw these instead of a base terrain.  Mountain/hill
> overlays or coastlines are drawn on top.  (Parts of the coast that display
> terrain are left transparent).

Now, this is slick.  But it makes me wonder if we can do even better. 
With regard to the blending of basic and complex terrains.

I don't know how civ1's graphics system worked.

The original freeciv drawing system blended the basic terrains manually
- but it couldn't blend disparate terrain, all the adjacent terrain is
considered either the same or different.

The civ2 system abandoned this, and simply used a blending mask to blend
adjacent tiles.  This doesn't give as much variety, but it cuts down on
the number of tiles needed by 60% and allows the blending of disparate
terrain.  It also used a quarter-tile system for coasts in addition to
the blending masks.

The civ3 system doesn't use an automatic blending at all.  Instead a
more complicated hand-drawing system is used.  This results in ~1500
sprites.  But the level of variety is immense; there are probably
millions of different possible combinations to form what we normally
think of as a "tile".

So, how can we get a good tile blending, with a lot of possible
combinations for tiles, without having to draw 1500 tiles?

Using different blending masks is a good idea.  Terrain-based blending
was my first thought, and apparently Daniel's as well.  Looks like this
system blends each edge of the tile independently based on the types of
the adjacent terrain.  This is primarily of use when a complex terrain
borders a basic one.

An alternate system could consider the diagonals as well.  To do this
you would want to do the blending masks by the quarter-tile, and you
only compare the terrain type rather than consider the "type".  I
believe this would involve 15 possible different tiles for each quarter
(so, 60 different total quarter-tiles).  The 15 possibilities: 0000 0001
0010 0011 0012 0100 0101 0102 0110 0111 0112 0120 0121 0122 0123.

Note, this would focus more on the blending of basic terrain rather than
complex terrain.  This wouldn't look at the _type_ of the terrain, only
compare to see if it was the same or different.

> The problem is that this is highly non-backwards-compatible and severely
> gtk-dependant.  I can clean up the backwards compatibility issues except
> that the new tileset (with partially transparent coastlines) will
> unavoidably break on the old code (the game will be playable, but with
> shifting artifacts).
> 
> The gtk issue is that under-dithering requires applying one sprite's mask
> to another's pixmap.  I considered making this a graphics_g function, but
> that seems to lead to severe memory leaks (allocate four sprites for every
> mountain hill and coast every time it's displayed and never reclaim
> it).  At present, I do this part of the drawing in gui-gtk/mapview.c which
> is not the most elegant solution (it simply lets me put all these
> sprites in one point on the stack, whereas returning them from a
> function would reuire them to take up different places on the heap).  If
> anyone can think of a better way, please let me know.
> 
> I'll try to get the patch cleaned up and sent out soon.  In the mean time,
> comments on design and aesthetics are much appreaceated.

Perhaps a bit more than you bargained for, the above was pretty much a
random rambling on the subject.

jason