[Freeciv-Dev] Re: (PR#7261) restructure tileset to avoid explicit terrain mention

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7261 >

Raimar Falke wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7261 >
> 
> On Sat, Jan 17, 2004 at 07:52:12PM -0800, Jason Short wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7261 >
>>
>>One problem with changing the tileset code at all is that there are too 
>>many special cases.  Most of these are related to terrain types.  Some 
>>examples:
>>
>>1. In orthogonal view all terrains are drawn as a single blended sprite. 
>>  Simple!
>>
>>2. In iso-view hills, mountains, and forests are treated separately. 
>>They are drawn as a dithered base terrain (grassland) with a blended 
>>special terrain on top.  All other terrains except ocean and river are 
>>drawn as a single dithered sprite.
>>
>>3. In iso-view river is drawn as a grassland with an S_RIVER sprite on 
>>top.  Orthogonal view has separate T_RIVER tiles (which blend together 
>>with ocean, although ocean doesn't blend with them).  (River terrain is 
>>only present in the civ1 ruleset.)
>>
>>4. In iso-view the coast is drawn using separate coastal sprites.  Each 
>>coastline area is assembled from 4 different subrectangular sprites.
>>
>>5. Mines on hills and mountains use a different sprite from those on 
>>desert and glacier.
>>
>>Making any changes to the drawing code is hard.  But making any changes 
>>to the terrain types is even harder.  There's no way to put support for 
>>such changes into the tileset, they have to go into tilespec.c.
>>
>>We discussed this a while ago, when Raimar and I agreed this is purely a 
>>tilespec issue; it shouldn't involve the server-side ruleset.  So after 
>>some though I have a design (and preliminary patch) to move toward this 
>>goal.
>>
>>- Currently for each terrain the ruleset specifies a sprite tag and 
>>alternate, like "t.arctic" or "t.forest".  The tileset uses this in its 
>>own special-casing way, loading the "t.arctic" flag and the 
>>"tx.s_forest_n0s0e0w0" sprites.  Under my design, the server just gives 
>>the client a terrain name and alternate to use for this terrain.  The 
>>(imaginary) association with actual sprite names is dropped, and it's 
>>left up to the client to determine how the drawing is done.
>>
>>For instance the "Forest" terrain will specify "forest" as its terrain, 
>>with no alternate.  Under a different ruleset the "Dark forest" terrain 
>>could have "mirkwood" as its terrain with "forest" as the alternate. 
>>The client will know how to draw both mirkwood and forest - possibly not 
>>in the same way.
>>
>>- The tilespec file will provide a list of supported terrains: "arctic", 
>>"forest", "mirkwood", etc.  For each terrain it gives information on how 
>>to draw this terrain.  This is in the top-level tilespec file: it is 
>>read when the tileset is first loaded, and only when the ruleset data 
>>arrives are tilespec terrains associated with ruleset terrains.
>>
>>- All terrains are handled with the same type of code, with as few 
>>special-cases as possible.  Ultimately any special-cases that do exist 
>>should refer to general terrain characteristics (like is_ocean) rather 
>>than specific ones (like T_RIVER).  The current form of the patch 
>>removes the special-casing of blending, dithering, and layering 
>>(basically points 1-2 above).
>>
>>Specifically, for each terrain we specify:
>>
>>- Whether it uses dithering.
>>- Whether it uses layering.
>>- Whether it uses blending, and if so which terrains it should be 
>>blended with.
>>
>>The tilespec code knows how to interpret these options.  It loads 
>>different sprites and draws a different way based on how they're set. 
>>But the tileset author should have a fair amount of leeway to change 
>>these options without any code changes.  Certainly this is incomplete, 
>>however: for instance dithering is currently tied to iso-view.
>>
>>In future this can be extended: first so that other special-cases are 
>>handled in the tileset rather than in the code, and secondly to allow 
>>new methods of drawing (like civ3's or Daniel/Rafal's cell-based drawing 
>>methods).
>>
>>Please comment on design or implementation.
> 
> 
> I like the idea and the design. 
> 
> Two issues:
> 
> Documentation, Documentation, Documentation. Really I don't know what
> dithering, blending and layering is here. Please explain it. Yes I
> know this is the first version of the patch and so doesn't contain
> much docu.

Yes.

These terms are mostly invented by me, but they should be discussed and 
probably improved, since they're a bit contradictory.

dithering: What iso-view does to meld two adjacent terrains together. 
It uses a dither mask and simply "blends" the two terrains together. 
Thus only one sprite is needed for each terrain.  The implementation is 
tied to iso-view and is gui-specific.

blending: What non-iso view does to meld to adjacent terrains together. 
    Say you have a grassland.  Each of the 4 cardinally adjacent tiles 
are looked at, and the grassland terrain that is drawn depends on which 
of these tiles is also grassland.  There are 16 sprites per terrain. 
Generally the terrain is only blended with identical terrain: forest 
with forest, hills with hills, mountains with mountains.  However in 
civ3 and some current tilesets hills and mountains are blended together. 
  This is controlled by the is_mountainous tileset variable which is no 
longer needed under the patch.

layered: What iso-view does to meld forest, hills, and mountains 
together with adjacent similar and different terrain.  First a base 
terrain (grassland) is drawn and dithered.  On top of this another 
terrain (forest, hills, mountains) is drawn and blended.  (This is 
similar to how S_RIVER is handled.)  Logically, if the terrain is 
layered then dithering refers to the bottom layer and blending to the 
top layer.  However it's also possible to mix-and-match combinations of 
dithering, blending, and layering.

cell-based drawing: civ3 uses a 4-cell drawing system that is also 
layered; Daniel and Rafal worked on a 2-cell draw system.  I won't 
explain this in detail here - they give much better results but require 
many more tiles.

The terms dithering and blending are not very accurate.  "dither" is 
what it is called in the code, but it would be more correct to call this 
blending.  Except what would we call blending then?

> Secondly I think
> 
> +[terrain]
> +
> +types = "arctic", "desert", "forest", "grassland", "hills", "jungle",
> +        "mountains", "ocean", "plains", "swamp", "tundra",
> +        "unknown", "t_river"
> +
> +arctic_dither = 0
> +arctic_layered = 0  
> +arctic_blend_type = 1
> 
> can be replaced with 
> 
> [terrain_arctic]
> dither = 0
> layered = 0  
> blend_type = 1
> 
> And than use secfile_get_secnames_prefix to get all "terrain_*"
> sections.

Yes.

jason