[Freeciv-Dev] Re: Topologies and coordinates

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Raimar Falke wrote:
> 
> On Fri, Oct 05, 2001 at 04:36:04PM -0400, Jason Dorje Short wrote:
> > Andrew McGuinness wrote:
> > >
> > > I think it is too ambitious to try to code the game to handle an
> > > open-ended variety of map organisations.
> > >
> > > The aim needs to be to identify and separate topology-sensitive
> > > parts of the code so that new variants can be added.
> > >
> > > What things that parts of the code need to know about can vary?
> >
> > Much less than you think.
> >
> > > 1  Calculating the 8 positions adjacent to a given position
> > >    (some of which may be off-map)
> >
> > No, this can just use normalize_map_pos.  Currently adjc_dir_iterate
> > does specialty checking for a border tile, saving a lot of time - this
> > may become a new function is_border_map_pos.
> 
> Andrew is right that calculating the 8 positions adjacent to a given
> position can be difficult (for example in map2).

True.

> > Raimar proposed some sort of mapping from mapspace to userspace, but
> > I don't think he had thought it out fully.
> 
> I still think that you need such code for IS_ARTIC and the isometric
> version of normalize_map_pos.

As a specialized case, yes - that's probably the easiest way to do it. 
I don't think it will be a real "mapping"; it'll just be used in a few
places.  Functions like distance_from_north_pole() and
distance_from_prime_meridian() would be useful.  It's only a simple
transformation, though, to convert these into get_lattitude() and
get_longitude(), which are more user-friendly.  In most/all cases this
should just be used by map generation code so speed should not be an
issue.

> > > This is the discussion that has been going on - whether it is general
> > > enough to assume that:
> > > >From (x,y) any tile ( x +/- 1, y +/- 1 ) is either
> > >  a) a valid tile adjacent to (x,y)
> > >  b) wraps to another tile (r,s) which is adjacent to (x,y),
> > >  c) is invalid
> >
> > You cannot ever assume this.  However, you *can* assume that
> > normalize_map_pos will tell you everything you need to know (assuming we
> > use map#1).
> 
> > The problem is most of the code doesn't use normalize_map_pos.
> 
> I don't understand this.

That "most of the code doesn't use normalize_map_pos"?  Actually, I
don't know much about the amount of code that *does* use
normalize_map_pos - I have a good idea that it's a lot, but the usage
and conversion looks pretty simple.  For the server, the remaining uses
of map_adjust_[xy] are small.  For the client, there are many remaining
uses of map_adjust_[xy] and it will be a real pain to fix them.

> > > The tradeoff is between generality and performance - having to use
> > > get_adjacent_tile() rather than the current iterate_xy macros would
> > > slow things down a bit, and it is not essential to implement the
> > > new topologies we really need.  On the other hand, not using it does
> > > restrict the wierd and wondeful topologies people might want to play
> > > with.
> >
> > As I said before, the current macros will work just fine (although they
> > too need to be fixed up a little bit).  There will be some slowdown
> > because the extra check for topology will be added, but this is
> > absolutely insignificant.  There is further slowdown because
> > normalize_map_pos and friends are functions rather than macros, but this
> > can be dealt with by making them inline.
> 
> I agree that the overhead for isometric maps can be made
> small. However I'm not sure about isometric maps.

It should be insignificant overall, I think.  Besides, since the
alternative is not having them I don't think that anyone should be
complaining.

jason