[Freeciv-Dev] Re: different iso drawing algorithms

[Rafa³ Bursig <bursig@xxxxxxxxx>]

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 ).
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 :
Yes I know that I don't see all aspect of this probleb but I know one 
key in mapdraw code is speed.
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;
}

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

Rafal

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