[Freeciv-Dev] generalization of cell-based drawing methods

[Jason Dorje Short <jdorje@xxxxxxxxxxxx>]

A non-isometric tileset has each terrain sprite covering exactly one 
tile.  I will call this a "1-cell" drawing method.  There is just one 
cell for the tile.
Iso-view tilesets keep this, for the most part.  However, oceans are 
drawn differently.  The tile is split up into four rectangular "cells". 
 For each cell there are 8 possible sprites.  Each cell corresponds to 
3 adjacent tiles (the corner and the two sides), and each of these 
adjacent tiles may be ocean or not-ocean.  Simple.
In the tileset file, this would be easy enough to generalize by adding a 
boolean or integer value num_cells.  For most terrains num_cells=1 and 
traditional drawing is used.  For ocean terrains num_cells=4 and 4-cell 
drawing is used.
But it doesn't end there.

Civ3 uses 4-cell drawing (for all terrain), but with two changes. 
First, the match type chosen isn't just a binary match (is-ocean or 
is-not-ocean) but is different for each terrain type.  Thus instead of 
2^3 different cells there are n^3 possible cells (n==number of terrain 
types).  Secondly, the cells are not drawn individually but in clumps of 
four.  The cell of ocean is clumped together with the adjacent cells of 
grassland, grassland, and plains into a single sprite.  Thus you could 
need a truly phenominal number of sprites.  Civ3 reduces this number by 
reducing the types of terrain (forest and jungle are both specials, 
hills and mountains are drawn layered just like we do) and by limiting 
the possible combinations (arctic only borders deep ocean, deep ocean 
only borders arctic and shallow ocean, shallow ocean only borders deep 
ocean and coastal ocean, grassland, plains, coastal ocean, desert, and 
tundra can all border each other but no more than 3 of them will meet at 
any cell center.  Terraforming to change the terrain type is 
impossible.)  Nonetheless Civ3 has many times more terrain tiles than we 
do.  However, the result is very good since each tile is hand-drawn and 
similar tiles are rarely shown near to each other.  In theory, with 
unlimited combinations you'd need n^4 different sprites (I think). 
Currently we have 11 terrains, however 5 of them (river, forest, jungle, 
hills, mountains) may not need drawing so we'd have 6^4=1216 sprites needed.
Daniel was working on a different system for cell-based drawing.  Here 
we again have 4 different cells per tile, but now each of them is a 
triangle.  The sprite for each cell is chosen based on the adjacent tile 
in that direction, so there are n different sprites for each cell.  And 
the cells are merged in clumps of two, each forming a rectangle.  This 
requires substantially fewer sprites than the Civ3 system (2n^2, I think).
My immediate question is how this information should be put into the 
tileset.  I want to add drawing information that will encompass all of 
these possibilities to the terrain grid in the tilespec file.  What I'm 
proposing is:
  ; Used for hills, mountains, forest, jungle
  layers = {1, 2, ...}

  ; Used for civ2-style "dithering"; bottom layer only
  is_blended = {0, 1}

  ; Matching means we choose a sprite based on adjacent terrain.
  ; None = no matching
  ; Boolean = Match against current match-type only
  ; Full = Match against ALL match-types
  layerN_match_system = {"none", "boolean", "full"}

  ; Gives the matching type for this terrain.  Matching will
  ; be done against all similar match types.  In cell-based
  ; systems the string is used in the sprite name.
  layerN_match_type = <string>

  ; Cell drawing method
  ; Single = 1 cell per tile
  ; Rectangle = 4 rectangles per tile
  ; Triangle = 4 triangles per tile
  layerN_cell_type = {"single", "rectangle", "triangle"}

  ; Boolean: do we merge cells with adjacent tiles
  layerN_cell_merge = {0, 1}

I haven't thought this out fully, so I'm not sure if the above is 
sufficient or if it can be made simpler.
Note that the different layers do need to be configured separately.  In 
civ3 mountains are drawn as
  layers = 2
  is_blended = 0
  layer1_match_system = full
  layer1_match_type = "g" ; grassland
  layer1_cell_type = rectangle
  layer1_cell_merge = 1
  layer2_match_system = boolean
  layer2_match_type = "m" ; hills, mountains
  layer2_cell_type = single
  layer2_cell_merge = 0 ; unused

so that both layers are matched.  But perhaps in this case it would be 
better to change layer1 to something like
  layer1_alias = grassland ; Draw as grassland.

?

Writing code to support all these options will not be easy.  But I think 
if we have a defined goal we can work toward it.  I'm just not sure what 
that goal should be.
Finally, note that all of the above options work identically in iso and 
non-iso view.  The sprites will obviously be different, and the drawing 
code will be a bit different (different offsets for cells, etc).
jason