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

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

<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.

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.

I haven't looked at the patch in detail.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  (On the statement print "42 monkeys"+"1 snake"): BTW, both perl and Python
  get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when 
  the answer is clearly "41 monkeys and 1 fat snake".  
    -- Jim Fulton, 10 Aug 1999