[Freeciv-Dev] Re: different iso drawing algorithms

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Sat, 2002-12-14 at 17:49, Raimar Falke wrote:
> On Sat, Dec 14, 2002 at 05:14:46PM -0500, Jason Short wrote:
> > On Sat, 2002-12-14 at 13:29, Raimar Falke wrote:
> > > On Sat, Dec 14, 2002 at 02:20:14AM -0500, Jason Short wrote:
> > > > On Fri, 2002-12-13 at 23:52, Rafa³ Bursig wrote:
> > 
> > > IMHO we have to consider two scenarios here:
> > >  1) updates of certain tiles and/or the city descriptions at the end
> > >  of the turn. Your patch decouples the in a nice way. While the patch
> > >  is ok the idea we follow is different: I see the first backing store
> > >  tile-based with easy update rules and the second backing store is for
> > >  all the objects which aren't tile-based (city descriptions, goto
> > >  lines, ...). So there is IMHO no need for any other layer.
> > 
> > There are 3 different ways we can separate this:
> > 
> > - Tile-linked gfx versus tile-independent gfx.  The only
> > tile-independent gfx AFAIK are city descriptions.  (Goto routes are
> > tile-linked.)
> 
> > - Below-animation gfx versus above-animation gfx.  Since the city
> > descriptions are normally drawn above units, it makes sense that they
> > should be drawn above unit animations.  Extending this idea, we can put
> > all animation gfx (including nukes, combat, etc.) on the same layer,
> > with graphics below and above.
> 
> I don't see what this buys us.

This gives better drawing quality!

> > - Static gfx versus dynamic gfx.  Static graphics take about 70% of the
> > redraw time, but they only need to be redrawn occasionally (usually when
> > the map canvas is recentered).
> 
> You get this with 2.b) for free.

No, not for free: you have to spend lots of memory and CPU to maintain
it.

> > Separating by #1 and #2 give us better drawing quality.  Each of them
> > can give better drawing speed if used properly.  I believe using 3
> > layers allows us to separate by all three.
> 
> I think that two layers are enough. In which case do you need three
> layers for speed?

layer 1: static tile-based gfx, below animation
layer 2: dynamic tile-based gfx, below animation
layer 3: dynamic non-tile-based gfx, above animation

> > >  2) recenter (other by mouse click or via packets): I see two
> > >  solutions:
> > >    a) make the backing store bigger (as large as the map) -> a lot of
> > >    memory for large tilesets
> > 
> > I have thought about this method, and then completely discarded it. 
> > Updating tiles that aren't on the canvas will be very slow.  And if we
> > don't keep then updated, what use are they?
> 
> Tiles updates are un-common. So this is possible.

And what about the city descriptions?  Will you update the whole world's
city descriptions every time any of them change?

> > Method c: don't redraw the full screen when a unit moves.  In many
> > cases when we do a recentering operation some or most of the old
> > canvas will still be visible - but its location has moved.  Thus we
> > don't have to redraw the whole screen.  See the attached image for
> > an example.  This is of particular use when the player is manually
> > recentering the screen - which is the situation when we most need
> > fast behavior.
> 
> This is only for the special case of unit movement.

Why do you say that?

My mistake: I said "when a unit moves"; I meant "when recentering the
canvas".

jason