Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: alternate topologies: isometric map
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: alternate topologies: isometric map
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Tue, 02 Oct 2001 11:37:54 -0400
Reply-to: jdorje@xxxxxxxxxxxxxxxxxxxxx

>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).

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

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)
#define map_outx(inx, x, y) (*x = inx % map.xize, *y = inx / map.xsize)
#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.

jason


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