[Freeciv-Dev] Re: different iso drawing algorithms

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Dec 14, 2002 at 06:06:27PM -0500, Jason Short wrote:
> 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!

It is possible to draw the animation on the first backing store. It
may cause some extra refreshes but these are local (4 tiles for a
move), uncommon and you also don't get flicker with this. Advantage is
that you don't need a third layer which is most of the time empty and
increase the cost of the normal draws.

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

I wouldn't say "lots". But yes 2.b) doesn't come free of charge.

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

The 3rd draw/blit/copy (which I think can be avoided) will slow down
the SDL client.

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

Yes. If you however can give numbers that this is very expensive we
may think about making it 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.
> > 
> > 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".

I would normally said: can you give some numbers. But this is hard
since it depends on the player (how often does he recenter and
how/where). The sprite merging for example allows a general speedup.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  A supercomputer is a computer running an endless loop in just a second