Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2004:
[Freeciv-Dev] (PR#8931) RFC: design for mapview layers
Home

[Freeciv-Dev] (PR#8931) RFC: design for mapview layers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] (PR#8931) RFC: design for mapview layers
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 7 Jun 2004 22:53:00 -0700
Reply-to: rt@xxxxxxxxxxx

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

Layers are needed to have cleaner / more accurate drawing.

Currently there is one function, update_map_canvas.  This draws all 
layers.  There is no possiblity to draw partial layers.  However some 
layers are separated within update_map_canvas:
   - City descriptions on top.
   - Goto lines underneath (iso only).
   - "Tiles" underneath that.
     Tiles includes everything else, which is way too much.  In non-iso
     view this includes a hack to draw goto lines.  It also includes
     the map grid.

Problems with the current system:

1. Drawing of goto lines are ugly.  For instance you might want to make 
the goto lines in non-iso view larger like they are in iso-view.  But 
this is impossible without significant code changes.

2. No possibility for separate layers for "tile" sprites.  This means 
each tile sprite must cover just _1_ tile, and if it overlaps onto 
adjacent tiles there are bugs.  This causes minor problems because some 
tile sprites (map grid, terrain) do overlap onto adjacent tiles; as a 
result there's a major hack to handle this.  And it makes including 
sprites that cover multiple tiles impossible.  Civ3-style roads and 
terrain sprites cover multiple sprites, and it would be by far easier to 
just draw them as they are.  But in the current system they must be 
split up into one sprite per tile covered by the "main" sprite.  This 
sounds ugly, and it is.

3. No possiblity for drawing things in between layers.  This is separate 
from #2; it's caused by the atomic nature of update_map_canvas.  For 
instance when a unit moves the unit starts out in the tile layer, behind 
goto lines and city descriptions.  But when the unit is animated it 
moves on top of the goto lines and city descriptions, and when it's done 
it goes back behind.  The result is slightly ugly drawing, but not a big 
problem at this point.

#1 is easy to fix, and should be done in any case.

#3 isn't that hard to fix, but I don't see much purpose in it at this point.

#2 is hard to fix, but with high payoff.  It's hard because the tile 
drawing is mostly done in tilespec.c when the sprite grid is filled. 
But this layer knows nothing about layers, and is fairly complicated.

-----

I'm not really sure what the eventual design should be.  But I have some 
suggestions for short-term improvements:

- Goto lines should be made into a separate layer, handled the same in 
iso and non-iso view.  This will simplify those (small) portions of the 
code considerably.

- update_map_canvas should work on a full layered system.  Something like:

   typedef void (*Layer_Drawing_Func)(struct canvas *pcanvas,
                                      int canvas_x, int canvas_y,
                                      int width, int height)

   Layer_Drawing_Func layers[] = {
     draw_tile_layer,
     draw_goto_layer,
     show_city_descriptions
   };

   void update_map_canvas(...)
   {
     for (i = 0; i < ARRAY_SIZE(layers); i++) {
       (layers[i])(...);
     }
   }

(draw_tile_layer and draw_goto_layer correspond to code currently within 
update_map_canvas.  show_city_descriptions will exist nearly unchanged.) 
  This design will allow the layers to be separated without further 
changes to update_map_canvas.  Of course the internals of 
draw_tile_layer will still have to be changed to break it up into 
multiple layers, which is the hard part.

jason




[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] (PR#8931) RFC: design for mapview layers, Jason Short <=