[Freeciv-Dev] Re: alternate topologies: isometric map

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 02, 2001 at 11:37:54AM -0400, Jason Dorje Short wrote:
> >From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
> >On Tue, Oct 02, 2001 at 03:04:17AM -0700, Jason Dorje Short wrote:
> 
> > > (1) remove all use of map_adjust_[xy] and replace with
> > > calls to normalize_map_pos (or the equivalent);
> >
> >I'm waiting for such patches.
> 
> One moment.
> 
> > > (2) remove all accesses to map.[xy]size;
> >
> >How do you plan to implement whole_map_iterate or similar things?
> >
> > > (3) make all map accesses independent of the map
> > > storage structure;
> >
> >What map accesses? There have to be methods which have to know how the
> >map is stored. At least common/map:map_get_tile and
> >server/maphand:map_get_player_tile have to IMHO.
> 
> Actually...
> 
> map_get_tile uses map_inx and so is independent of the topology being
> used (so long as map.tiles is set up as an appropriately sized array). 
> Most other code in map.c still uses (x + y * map.xsize), which is
> certainly not independent (I know you have been trying to make map_inx
> more widespread).

The cleaner solution is IMHO to use map_get_tile for the other
code. Costs performance. Maybe make map_get_tile a macro.

> (BTW, why is it called map_inx?  That seems a rather random name.  I
> will likewise choose map_outx as its inverse.)

inx short for index.

> I was thinking that if we set up all map structures (there are multiple
> of them, scattered throughout the code) as arrays then map_inx and
> related functions/macros can be used to index into them.
> 
> #define map_inx(x, y) (x + y * map.xsize)

map_pos_to_index

> #define map_outx(inx, x, y) (*x = inx % map.xize, *y = inx / map.xsize)

index_to_map_pos

> #define map_size() (map.xsize * map.ysize)
> 
> #define whole_map_iterate(x, y) { \
>   int inx, x, y; \
>   for (inx=0; inx < map_size(); inx++) { \
>     map_outx(inx, &x, &y);
> 
> #define whole_map_iterate_end } }
> 
> Currently this would break down to the same code we have now in most
> cases (not for whole_map_iterate; that would be very slightly slower BUT
> would be a single loop that could be broken out of).  Later adding
> alternate topologies would mean making map_inx, map_unx, and map_size
> more complicated (probably moving them into inline functions).
> 
> For alternate topologies, there is still the question of numbering. 
> Reiner's link pointed to a rather lengthy discussion on that topic for
> the isometric maps.  This is really a question for later, though.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I heard if you play the NT-4.0-CD backwards, you get a satanic message."
 "That's nothing, if you play it forward, it installs NT-4.0"