[Freeciv-Dev] Re: different iso drawing algorithms

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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.

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

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.

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

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

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.

Unfortunately this is not easy to implement without a lot of GUI code.

jason