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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Oct 18, 2001 at 11:53:08AM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> 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

The DISTANCE_FROM_SOUTH_POLE isn't needed since
DISTANCE_FROM_SOUTH_POLE = height - DISTANCE_FROM_NORTH_POLE. But
you may introduce a DISTANCE_FROM_WEST_POLE.

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

I think the idea is good but need integration into the (to be created)
framework. So if there is a map.topology.height there should be a
get_height_of_map_pos(x,y) which has a range of
[0..map.topology.height-1]. Same for width. Or an
transform_to_xyz_system(&width,&height,x,y). The question is: how is
the new system named?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "These download files are in Microsoft Word 6.0 format. After
  unzipping, these files can be viewed in any text editor, including
  all versions of Microsoft Word, WordPad, and Microsoft Word Viewer."
    -- http://www.microsoft.com/hwdev/pc99.htm