[Freeciv-Dev] Re: different iso drawing algorithms

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Fri, Dec 13, 2002 at 04:30:30PM -0500, Jason Short wrote:
> On Fri, 2002-12-13 at 12:24, Raimar Falke wrote:
> > On Fri, Dec 13, 2002 at 03:02:23PM +0100, Rafa³ Bursig wrote:
> > > Dnia 2002.12.13 10:35 Raimar Falke napisa³(a):
> 
> > Why do you insisted on a flush function which take a rectangle? It is
> > unneeded. We can built the whole system on these two functions:
> 
> But I want to build it on only one function:
> 
>   flush_map_canvas(canvas_x, canvas_y, pixel_width, pixel_height);
> 
> The problem is that we are talking of two completely different things.
> 
> >   void mapcanvas_dirty_canvas_rectangle(canvas_rectangle);
> >   void mapcanvas_dirty_flush(void);
> > 
> > Some wrapper functions for dirting map positions may be nice and
> > required. So the users (packhand.c, control.c, ...) only have to dirty
> > certain parts. Than million cycles later we found out that we got all
> > data from the network. At this point we redraw all the regions we have
> > dirtied before (call mapcanvas_dirty_flush). mapcanvas_dirty_flush
> > can't and won't take a region of a canvas. This also means that no
> > function will take a write_to_screen parameter anymore. The flow is
> > like this:
> > 
> >   packhand.c:handle_tile_info calls
> >   mapview_common.c: map_dirty_tile (this function can't calculate the
> >                     canvas position since the map will be moved later,
> >                     so it will save the map position in some list)
> > 
> > later
> >  packhand.c:handle_freeze_hint calls
> >  mapview_common.c:mapcanvas_dirty_flush which goes through the dirty
> >                   lists (one for map positions and one for canvas
> >                   rectangles) and creates a unique list of map tiles
> >                   which need updating. Than it calls draw_tile
> >                   (something like pixmap_put_tile or put_one_tile) for
> >                   the dirty tiles. At the end it calls
> >                   mapcanvas_update_screen (which is something like
> >       get_canvas_xy(x, y, &canvas_x, &canvas_y);
> >       gdk_draw_pixmap(map_canvas->window, civ_gc, map_canvas_store,
> >                       canvas_x, canvas_y,
> >                       canvas_x, canvas_y,
> >                       width*NORMAL_TILE_WIDTH,
> >                       height*NORMAL_TILE_HEIGHT);
> > 
> > For better efficiency mapcanvas_dirty_flush should maybe operate on
> > tiles rectangles and not single tiles. This allows certain speed ups
> > in the draw_tiles functions.
> 
> The system Rafal and I are talking about tracks which part of the
> backing store are dirty, and need to be flushed to the screen.  Thus all
> the flush() function (which may be internal to mapview_common) has to do
> is flush the dirty parts to the display using flush_map_canvas.  This is
> simple, and it is structurally similar to the current code.  But, it
> requires that we do *all* of the drawing; the only place we save is on
> writing to the display (which is huge).

Ahhh I see. So we are talking about the map_canvas_expose and here
especially this code:

        gdk_draw_pixmap( map_canvas->window, civ_gc, map_canvas_store,
                ev->area.x, ev->area.y, ev->area.x, ev->area.y,
                ev->area.width, ev->area.height );
        show_city_descriptions();

But where in common client code would you need to call such a
function? IMHO there isn't one case. AND I think that we won't
abstract (move it into common client code) the backing store
(map_canvas_store). So except for the ugliness of the
show_city_descriptions call from above I don't a problem. I also think
that these updates (multiple copies backing store -> screen) aren't a
problem.

> Your system marks map tiles as dirty, so that they can be redrawn only
> later.  Note that "flush" is not the right word here.  And your system
> is not a replacement for ours, because you REALLY do not want to rewrite
> the entire backing store to the display with every change.  It is a
> longer-term goal IMO.

I intended that my basic drawing functions (draw_tile or draw_tiles)
write into both the backing store and the screen.

> Note the current terminology is somewhat confused.  Right now we have:
> 
>   update = update something that has changed, maybe write_to_screen
>   refresh = same as update
> 
> "flush" has the meaning that we're using it for.  What you're using it
> for should be called "refresh" IMO - except that this is already
> (confusingly) taken.

So let me attach the tag "dirty" to my concept.

> > Mhh thinking about this also leads to the conclusion that you _can't_
> > pass canvas coordinates to the dirty functions since the canvas may be
> > recentered. Only the map positions stay invariant/fixed. So the
> > 
> >   void mapcanvas_dirty_canvas_rectangle(canvas_rectangle);
> > 
> > from above needs to be changed to:
> > 
> >   void mapcanvas_dirty_tiles(int x, int y, int width_in_tiles, int 
> > height_in_tiles);
> 
> How does this work in iso versus non-iso mode?  What is the rectangle
> defined by it?

The gui-depend draw_tiles function have to take care of drawing all
parts of the tile.

> > > Each client should have own implementation of those functions. ( 1), 
> > > 2), 3) )
> > 
> > I'm very sure that won't be the case. The implementation of
> > mapcanvas_dirty_canvas_rectangle is GUI independent. So is a certain
> > part (managing the list if dirtied rectangles) of
> > mapcanvas_dirty_flush.
> 
> Rafal has said that gui-SDL can do it faster.  But I don't know if this
> is because SDL can accelerate it somehow or just because he wants to use
> SDL_Rect structures and so save on a few instructions of memory copying.
> 
> > I don't understand this. Maybe I don't want to understand it.
> 
> He is using the per-pixel method of flushing (which is good).  He is

flushing == coping from backing store to screen?

> hard-coding isometric loops in some places (which is good).  He is also

This is good? IMHO not.

> hard-coding a torus world (which is bad).

> Rafal: there are a couple of places where update_map_canvas() is called
> that are neither a (1,1) square nor the entire visible canvas.  For
> instance when removing a goto line we may redraw a (2x1) area.  So we
> may be able to change things as you suggest, but first they need to be
> moved into mapview_common.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "SIGDANGER - The System is likely to crash soon"