[Freeciv-Dev] Re: different iso drawing algorithms

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

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.

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

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

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

> >    b) prepare tiles or more general lists of sprites: see
> >    
> > http://lists.complete.org/freeciv-dev@xxxxxxxxxxx/2001/08/msg00194.html.gz
> >    and
> >    
> > http://lists.complete.org/freeciv-dev@xxxxxxxxxxx/2001/10/msg01036.html.gz.
> 
> This method has merit.  I haven't looked at the provided patches yet,
> but my initial idea would be to pre-assemble rail and road sprites.  By
> building 512 additional sprites at the beginning (or on demand) we can
> cut down on the number of drawn sprites by about 6/tile.  I suspect this
> would be less effective than using a bottom layer of static graphics,
> but it would make recentering operations faster.

You do this on demand. I have updated my solution. The update is
probably buggy and I get a segvs but the graphics look ok. Results:

Start game:
2: Filling tile sprite cache...
2: ...done. Cache contains 20 entries
2:   7 times were 1 sprites merged
2:   8 times were 2 sprites merged
2:   4 times were 3 sprites merged

Disband all units, see whole map without FOW:
2: Filling tile sprite cache...
2: ...done. Cache contains 329 entries
2:   84 times were 1 sprites merged
2:   198 times were 2 sprites merged
2:   47 times were 3 sprites merged

Normal midgame:
2: Filling tile sprite cache...
2: ...done. Cache contains 615 entries
2:   60 times were 1 sprites merged
2:   137 times were 2 sprites merged
2:   209 times were 3 sprites merged
2:   153 times were 4 sprites merged
2:   45 times were 5 sprites merged
2:   10 times were 6 sprites merged

So in the last case we reduced the number of (basic tile) draws by
about 3.

The patch is non-iso mode only.

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

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
    1) Customers cause problems.
    2) Marketing is trying to create more customers.
  Therefore:
    3) Marketing is evil.

tile_sprite_cache2.diff
Description: Text document