[Freeciv-Dev] Re: PATCH: rand_pos function and usage (PR#1017)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Oct 19, 2001 at 02:48:45PM -0400, Jason Dorje Short wrote:
> Raimar Falke wrote:
> > 
> > I know that such distances aren't available on all topologies. However
> > the non-iso rectangle and the iso-rectangle has such distances. And
> > yes I would also prefer to have a distance_from_[nwse]_edge. This
> > would be the base where other stuff like distance_from_[ns]_pole can
> > be defined. I also agree that map.topology.height is more a
> > map.topology.max_height.
> 
> OK, so we have distance_from_[nwse]_border - let's call a border area
> where wrapping may occur a "border" and one where there is no wrapping
> an "edge" (unless you have a better idea; I just want to make the
> distinction).

This is ok as long as you write it down.

> We'll also have distance_from_pole (or maybe
> distance_from_[ns]_pole) and distance_from_edge as wrappers.  Then we've
> also got the height and width of the map, which may or may not
> correspond to map.topology.[height|width], and total_polar_distance as a
> wrapper for this.
> 
> The attached patch is an example of what I'm looking at for mapgen.c. 
> Aside from the rand_pos changes, it converts everything to use
> whole_map_iterate with the appropriate polar distance check.  (It has no
> appreciable impact on the speed of standard map generation.)


> +#define DISTANCE_FROM_POLE(x, y)      \
 +#define MIN_DISTANCE_FROM_POLE(x, y)      \

> +#define TOTAL_POLAR_DISTANCE( ) (map.ysize)

This shouldn't be a function.

Overall: it goes in the right direction. If we now adjust rand_pos
accordingly I will be happy.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Two OS engineers facing a petri net chart:
        "dead lock in four moves!"