[Freeciv-Dev] civ3 drawing system

[Jason Dorje Short <jdorje@xxxxxxxxxxxx>]

The civ3 drawing system is hard to use with our current drawing 
algorithm, because the current method is entirely tile-based.  With the 
current algorithm, we draw tiles (map positions) one at a time.  For 
each tile we call fill_tile_sprite_array() which gives us a list of 
sprites to draw.  Then the drawing code draws these sprites, does 
dithering, draws the map grid, etc.
In civ3 the basic terrain sprites don't cover individual tiles.  A 
single terrain sprite covers 1/4 of each of 4 adjacent tiles.  Hence the 
above algorithm won't work directly.
There are two ways we can work around this.

The better, but much harder method is to change the drawing algorithm. 
This basically amounts to merging the code in fill_tile_sprite_array, 
put_one_tile, and update_map_canvas - and then reordering it.  So 
instead of looping over all tiles to draw the sprites on that tile, we 
would first draw the bottom-level terrain, then the next level of 
terrain, units, etc.  This method is better because it's faster and more 
elegant than the alternatives (see below).  But it will take lots of 
changes, and I don't know how we could do city maps using it.
The worse, but much easier method is to split up the sprites before 
drawing them.  The split can either be done in the tileset (hard to 
maintain) or in the code (takes extra code).  Now instead of 1 sprite 
composing 4 cells, we draw each of the cells individually.  Each cell is 
associated with just one tile, so the above problem goes away.  But now 
we have to split up the tiles at runtime by applying a second mask.  For 
instance we may have a diamond-shaped tile 64x32 and we want to take the 
top 1/4 of it (which is itself diamond-shaped).  This will take a new 
GUI function apply_mask_to_sprite() or some such.  And now in the 
drawing we have to draw 4x as many sprites (of 1/4 size), which will 
take longer.
I'm leaning toward the second method since it at least seems possible.

jason