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

[jdorje@xxxxxxxxxxxxxxxxxxxxx]

Raimar Falke wrote:
> 
> On Thu, Oct 18, 2001 at 11:13:48AM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> > Raimar Falke wrote:
> > >
> > > On Wed, Oct 17, 2001 at 10:01:24PM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx 
> > > wrote:
> > > > The attached patch creates a function, rand_pos(&x, &y) that determines
> > > > a random map position.  It also uses it in place of all similar code.
> >
> > > > This could have efficiency problems if we were looking for a very small
> > > > subset of positions on the map.  Fortunately, there is no such code
> > > > right now.
> > >
> > > I'm also converned about efficiency problems. Can't rand_pos take the
> > > range of allowed distances from north. Which now are from
> > > 0..map.ysize-1 and latter come from 0..height-1.
> >
> > This doesn't sound so good.  Outside of map generation stuff (which
> > shouldn't be a concern), the only check that's done on the returned
> > value is to make sure it's not on one of the poles.  In other words,
> > this will attain virtually no speedup except during map generation.
> >
> > This method also isn't really very general.  For instance, how does it
> > apply to a torus map?  A torus map would probably have no polar regions
> > (everything would be tropical); this would be easy to achieve using the
> > checks I'm proposing but difficult or impossible if you build that
> > information into the rand_pos function.
> >
> > Finnaly, this would make the code much uglier (IMO) and would make
> > rand_pos a topology-dependent function, which I'd like to avoid.
> 
> The map generation is topology-dependent. The placement of certain
> items (rand_pos is used for this) is topology-dependent. So I have no
> problem of having a topology-dependent rand_pos method. This method
> has to have a certain knowledge about latitude. But method for this
> are needed for the general map creation anyway.
> 
> So what do you think about a general rand_pos method and a map
> generation rand_pos method. The second one is local to mapgen.[ch].

I don't think map generation has to be particularly topology-dependent,
at least not the part you're talking about.

BTW: the map iteration patch did not touch mapgen.c because I plan a
separate fix for there.

I plan a macro DISTANCE_FROM_NORTH_POLE(x,y) which will replace the
current use of "y" in most of these places.  Similarly, a macro
DISTANCE_FROM_SOUTH_POLE(x,y) can replace the current use of
"map.ysize-1-y" (which is sometimes incorrectly referred to as
"map.ysize-y", I believe).  Instead of using map.ysize in the
calculations, we'll use TOTAL_POLAR_DISTANCE().  Introducing a fourth
macro, DISTANCE_FROM_POLE(x,y) to be the minimum of the distance from
the north and south pole allows lots of the code to be made much
cleaner.

These macros (well, all but the fourth one) are topology-dependent, but
they're pretty easy to write for most topologies.  Using them will make
it pretty easy for specific topologies to have different types of maps
under the same mapgen code: for instance a torus map would probably not
have any poles, so would always have
DISTANCE_FROM_POLE(x,y)==TOTAL_POLAR_DISTANCE()/2, making everything
tropical.  (This idea was proposed by Reinier; a torus map done this way
makes things fairer in multiplayer mode.)  It is not easily achievable
if things are done as you propose.

Ultimately, there may be more problems with the mapgen code and some map
generators may not work for specific topologies.  This will be a deeper
problem, though, and won't have such a simple solution.

jason