Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2002:
[Freeciv-Dev] Re: different iso drawing algorithms
Home

[Freeciv-Dev] Re: different iso drawing algorithms

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Cc: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: different iso drawing algorithms
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Sun, 15 Dec 2002 13:39:25 +0100

On Sun, Dec 15, 2002 at 07:34:02AM -0500, Jason Short wrote:
> On Sun, 2002-12-15 at 07:19, Raimar Falke wrote:
> > On Sun, Dec 15, 2002 at 07:04:04AM -0500, Jason Short wrote:
> > > On Sun, 2002-12-15 at 06:54, Raimar Falke wrote:
> > > > 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:
> > > 
> > > > > > > - 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.
> > > 
> > > Here I am not talking about flicker but about having the texts not
> > > disappear when single-tile updates and animations happen.  I do not know
> > > of any other way to do this besides having a separate buffer.
> > 
> > So what is the problem? Current situation (drawn in this order):
> >  1) tiles (from backing store)
> >  2) city descriptions
> >  3) animations
> 
> This is only the case for update_map_canvas_visible.  For
> refresh_tile_mapcanvas() or any of the animation functions the order is:
> 
> 1) Tiles (from backing store)
> 2) Animation
> 
> and there is no possibility for drawing city texts.
> 
> In principle we could draw the city graphics from nearby cities;
> however, the code is not structured to support this.  Also, we don't
> really know how nearby they can be.

But we change these functions to so that they use the second backing
store with the city descriptions?!

> > Proposed:
> >  1) tiles and animation (from first backing store)
> >  2) city descriptions (from second backing store)
> 
> I still feel this method is best.  But as I said, I value correctness
> very highly.  I doubt it would be slower than the current method.

I don't see a problem if all code is changed to follow the proposal.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Windows: Where do you want to go today?
 Linux: Where do you want to go tomorrow?
 BSD: Are you guys coming or what?



[Prev in Thread] Current Thread [Next in Thread]