[Freeciv-Dev] Re: different iso drawing algorithms

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Dec 12, 2002 at 11:45:49AM +0100, Rafa³ Bursig wrote:

The quotings you produce a corrupted. Please fix this.

> Dnia 2002.12.12 01:44 Jason Short napisa³(a):
> >On Wed, 2002-12-11 at 18:20, Rafa³ Bursig wrote:
> >> Dnia 2002.12.11 21:04 Jason Short napisa³(a):
> >> > On Sun, 2002-12-08 at 05:16, Jason Short wrote:
> >> >
> >> > > So, the question becomes: which system is better?  Should we
> >support
> >> > > just one of them, or try to support both?
> >> >
> >> > The tricky buffered drawing system requires slightly more GUI code
> >to
> >> > do
> >> > the buffering.  A disadvantage is that it can only draw
> >> > iso-rectangles.
> >> > So if we update a 1x1 area we're fine.  But if we draw a 2x1
> >rectangle
> >> > (as sometimes happens) we have to draw a couple of extra tiles.
> >If we
> >> > redraw the entire mapview, then the current algorithm ends up
> >> > iterating
> >> > over 4x as many tiles as are necessary - but this inefficiency can
> >be
> >> > eliminated with a better algorithm.
> >> >
> >> Here is some code that make SDLClient compatible with new
> >unification
> >> of update_map_canvas.
> >
> >Note that update_map_canvas() hasn't been unified yet (because of the
> >drawing algorithm differences).  Nor has one of the drawing algorithms
> >been chosen yet...
> >
> Yes I know about it but I want make SDLClient working with it.
> This change make draw code woking.
> 
> Problem here was unification of positioning system ( have diferent 
> result that my ).

> Before unification I have my own system ( only iso ) and code work.
> When you make unification part of code use common system ( exp. drawing 
> city names ) and rest my stystem ( drawing map ).

In the medium term (next months) the SDL client should also be able to
use non-iso tilesets. This is a goal.

> This patch drop all code of my draw and positioning systems and use 
> only common systems but for cost of speed.
> 
> I remove from patch all buffering code ( in common ) and leave only two 
> new functions  draw_map_widgets() and update_iso_map().
> 
> >> I made here some try to speed up draw full screen map.
> >>
> >> I think that we should make dedicatet funct. to draw one tile, full
> >map
> >> , etc not one unificated function to draw all cases.
> >
> >I think you are not looking far enough ahead.  IMO the drawing
> >primitives the GUI provides should be lower-level than that.  But one
> >step at a time...
> First I speak here about ISO maps.

> Secound :

Do you mean "Second point"?.

> Yes I know that I don't see all aspect of this probleb but I know one 
> key in mapdraw code is speed.

Yes but speed isn't the only key aspect of map drawing.

> 1) When we draw more than 1 tile and less that full screen ( I know 
> about city map )
> 
> 2) As I say before we don't need one unificated draw dunction but more 
> specialised functions like :
>   - draw full screen map. - common
>   - draw city map - common or GUI
>   - draw one tile ( used by "draw full screen" funct, draw only one 
> tile ) - GUI
>   - draw single tile ( here we must use one of two know algoritms to 
> draw neighbours tiles ) - GUI
>   - we can leave update_map_canvas( ... ) to support other cases.

> 3) I'm not much experienced programmer byt have  we any speed up if we 
> change client api API
> From :
> 
> int draw(...) {
> ...
> if (isometric)
> do something
> else
> do something
> }
> 
> To
> 
> int (*DRAW)(...);
> 
> int iso_draw(...)
> {
> do something
> }
> 
> int noiso_draw(...)
> {
> do something
> }
> 
> void init()
> {
> if (isometric)
>   DRAW = iso_draw;
> else
>   DRAW = noiso_draw;
> }

This won't you buy anything. You trade one branch miss prediction
against a function call (just look at the prologue and epilogue of a
normal function).

> 4) BUFFERING, as i say before we need funct. that save updatet rect and 
> then flush those rects.
> exp.
> 
> #define MAX_RECT 50;
> struct rect {
>   int x, y, w ,h ;
> }saved_rects[MAX_RECTS];
> int count_of_rects;
> 
> void save_rect( int x , int y , int w , int h )
> {
>   if ( count_of_rects < MAX_RECTS ) {
>     saved_rects[count_of_rects].x = x;
>     saved_rects[count_of_rects].y = y;
>     saved_rects[count_of_rects].w = w;
>     saved_rects[count_of_rects++].h = h;
>   }
> }
> 
> flush_rects(void)
> {
>   if ( count_of_rects > MAX_RECTS ) {
>      /* flush fullscreen */
>   }
>   else
>   {
>      /* flush rect array */
>   }
>   count_of_rects = 0;
> }

I agree we need something to dirty specific regions. While I also
agree that the implementation may use an array or a list of rectangles
I think that the interface should contain these functions:
 void mapcanvas_dirty_tile(map_x,map_y);
 void mapcanvas_dirty_rectangle(map_x,map_y,width,height);
 void mapcanvas_dirty_visible();
 void mapcanvas_dirty_all();
than there is a
 void mapcanvas_dirty_flush();
which does the updating. The nice thing is that this can be coupled
with FREEZE_HINT/THAW_HINT to given maximum performance (minimal
number of refreshes). One problem is that this doesn't work with
animations. In this case we have to replace gdk_flush with
mapcanvas_dirty_flush.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Real Users find the one combination of bizarre
   input values that shuts down the system for days."