[Freeciv-Dev] Re: different iso drawing algorithms

[Rafa³ Bursig <bursig@xxxxxxxxx>]

> > > 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.
I rather plan it in long term after fixing draw code :)

> > 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"?.
no "Secoundo 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.
Major key is speed !!!
Resently I saw Civ3 in action and with all nice gfx and animation speed 
of this game was poorly.
This was on celeron 333 and what hapend when I run this game on my 
P233MMX :)

> > 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).
Yes and No :)
This reduce size of function and in some cases like positionig system 
it is better becouse we can make them INLINE.
In draw loop we ofen use something like that

for( x .... )
  for( y ... )
	if (get_canvas_xy(x,y, canvas_x , canvas_y )) or if ( 
map_pos_to_canvas_pos( ... ) )
       {
          draw(...);
       }

IMO those functions ( get_canvas_xy( ... ) or 
map_pos_to_canvas_pos(...) ) should be small and inlined becouse this 
will reduce jup outside loop.
> > 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);
map_x , map_y - can be tile position on map.

>  void mapcanvas_dirty_rectangle(map_x,map_y,width,height);
if this function work like  "save_rect( int x , int y , int w , int h 
)" then
map_x , map_y should be pixel tile positon on screen.( canvas_x , 
canvas_y )
>  void mapcanvas_dirty_visible();
>  void mapcanvas_dirty_all();
This is't needend becouse we can have "mapcanvas_flush_fullscreen(void)"

> 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.
No we need another funct to do that :
void mapcanvas_flush_rectangle(canvas_x,canvas_y,width,height);
this should be used with animation and make flush of rect.

Rafal

----------------------------------------------------------------------
Zostan trenerem kadry skoczkow i wygraj bilet pod skocznie!
> > > http://link.interia.pl/f16a5