Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2001:
[Freeciv-Dev] Re: Profiling Civserver again
Home

[Freeciv-Dev] Re: Profiling Civserver again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Profiling Civserver again
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxxxx>
Date: Thu, 26 Jul 2001 01:39:26 +0300 (IDT)

Wow,


On Wed, 25 Jul 2001, Trent Piepho wrote:

> Now, take the DIR_DX and DIR_DY arrays that give the offsets for the 8
> neighbors and make them into 9 by 8 arrays.  DIR_DX[0][] would give the eight
> offsets for a "type 0" tile, one which is in the upper left corner. 
> DIR_DX[8][] would give offsets for a "type 8" tile, which is in the interior

this is certainly a great solution, but isn't it just a little bit too
convoluted?

Since the most of the tiles are of the type "8" -- inner tiles, wouldn't
it be simpler just to check for type 8 and if yes, don't do any more
checks and if not, then do the normalize bit.

That is, in Jason's patch add

char is_border_tile=((center_y==0)||(center_y==map.ysize-1) ||
                    (center_x==0)||(center_x==map.xsize-1));

before the for() loop and then inside the loop do

if (is_bother_tile) {
/* do the renormalization thing */
}

and that's it.
Of course people might want to do some more profiling (sorry, cannot do it
myself, I am away), but I am 95% sure that the above will be almost as
fast as Trent's algorithm.

G.

P.S. And please somebody optimize map_adjust_x

> of the map.  The DIR_DX and DIR_DY arrays would look something like this.
> 
> #define XX    MAX_INT         /* XX is a marker that means skip */
> #define WR    (-map.xsize)    /* wrap off the right edge */
> #define WL    (map.size)      /* wrap off the left edge */
> /* NW corner tile */
> DIR_DX[0][] = { XX, XX, XX, WL,  1, WL,  0,  1};
> DIR_DY[0][] = { XX, XX, XX,  0,  0, -1, -1, -1};
> /* interior tile */
> DIR_DX[8][] = { -1,  0,  1, -1,  1, -1,  0,  1};
> DIR_DY[8][] = { -1, -1, -1,  0,  0,  1,  1,  1};
> 
> 
> The current iterate code looks like this:
> 
> #define adjc_dir_iterate(x, y, x1, y1, dir)   \
> for (dir = 0; dir < 8; dir++) {                       \
>   x1 = x + DIR_DX[dir];                               \
>   y1 = y + DIR_DY[dir];                               \
>   if (normalize_map_pos(&x1, &y1)) {          \
> 
> #define adjc_dir_iterate_end \
>   } \
> }   \
> 
> Unfortunately it wasn't placed inside an iterator macro, but if it had been,
> that's what the macro would be.
> 
> This is my new iterator macro.  It doesn't perform any adjustments on the
> coordinates, those are already build into the DIR_DX and DIR_DY arrays.
> 
> #define adjc_dir_iterate(x, y, x1, y1, dir)   \
> { int type = map_tile_boundary_type(x,y);       \
>   for (dir = 0; dir < 8; dir++) {             \
>     if(DIR_DX[type][dir] == MAX_INT) continue;        \
>     x1 = x + DIR_DX[type][dir];                       \
>     y1 = y + DIR_DY[type][dir];                       \
> 
> #define adjc_dir_iterate_end \
>   } \
> }   \
> 
> It also needs a new function to get a tile's type:
> 
> int map_tile_boundary_type(int x, int y)
> {
>   if(y==0) {                                  /* +---+---+---+ */
>     return x==0? 0 :(x==map.xsize? 2 : 1 );   /* | 0 | 1 | 2 | */
>   } else if(y==map.ysize) {                   /* +---+---+---+ */
>     return x==0? 3 :(x==map.xsize? 4 : 8 );   /* | 3 | 8 | 4 | */
>   } else {                                    /* +---+---+---+ */
>     return x==0? 5 :(x==map.xsize? 7 : 6 );   /* | 5 | 6 | 7 | */
>   }                                           /* +---+---+---+ */
> }
> 
> I think this is going to be a pretty fast way to iterate around adjacent
> tiles.  A similar technique can be used to speed up some of the other iterator
> macros, like cartesian_adjacent_iterate, which is quite crude.  I also wonder
> why adjc_iterate is abbreviated and cartesian_adjacent_iterate is not.  Who
> wrote that code, anyway?
> 
> 
> 






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