[Freeciv-Dev] Re: (PR#6721) A Quincuncial topology

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6721 >

Your example is too complicated, but shows the relationships around
the centre view correctly.

You only need a double sized map to represent this trivially with
almost no code change. Just drop the top or bottom miniscule set.
and duplicate/invert the map once, caching the result as a normal
wrapped map with twice the capacity.

One can start from this working back in changes for various issues.

The travel directions are handled automagically by normal centring
and normalization functions. The orientation of the map centre sets
the directions. For example, if you run over the pole, you don't
change the local direction sense until the map centre also goes over
the pole, then the normalization process will flip the map back to
the standard/normal form.

The areas of concern are when the caching needs to be replaced with
direct lookups, but it might be possible to handle this with nothing
more than correcting coordinate transform functions. The trick is to
remember when you are in the cached region and either read/write
through or continue to work with things in cached form.

But, almost no code needs to be changed outside of coordinate
transformations, with the possible exception of an understanding of
when cached vs normal coordinates are being used. Most of your
problems below are as usual, not technical problems, but semantic
ones from taking a poor definition as ones starting point, and then
propagating the complexities instead of looking for the simplifying
viewpoint.

Cheers,
RossW
=====

Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6721 >
> 
> Summary:
> 
> This topology is a crazy, kinda cool approximation of a sphere.  To get
> it to work we'd have to have something that I will call
> "mirror-wrapping".  For instance an 8x3 map that mirror-wrapped in the Y
> (north-south) direction would look like
> 
>   xwvutsrq
>   ponmlkji
>   hgfedcba
>   ABCDEFGH
>   IJKLMNOP
>   QRSTUVWX
>   xwvutsrq
>   ponmlkji
>   hgfedcba
> 
> where the capital letters are the normal positions (0,0) through (7,3).
>  Thus for each Y wrap there is a mirroring of the X value
> 
>   Y = Y + map.ysize
>   X = map.xsize - 1 - X
> 
> which makes the math complicated, but possible.  Note that you can have
> a mirror-wrap in both X and Y directions, or mirror-wrap in one and wrap
> in the other: the cartesian constraints imposed by two-dimensional
> display are satisfied with any combination.
> 
> The two quincuncial topologies that have been described so far are
> approximations of a sphere.  One is a rectangular (dimensions 2x1) map
> which mirror-wraps in Y and wraps in X.  The other has a square map with
> mirror-wrapping in both X and Y directions.  I believe PNG files
> demonstrating both of these are included earlier in the ticket.
> 
>>From a topologist's point of view, this is a reasonable approximation of
> a sphere.  For instance with the first quincuncial topology if you head
> across one of the poles you end up coming down south on the other side
> of the world, just as you'd expect.  E.g., if you head north from Canada
> you end up in Russia.  This is not perfect, however: it only works if
> Canada is situated properly.  Otherwise you might head north from Canada
> and end up in...Canada.
> 
>>From a core-implementation point of view, the problems in implementing
> this haven't been well studied.  However I believe there will be a
> problem with many users of vectors.  For instance if you travel north
> from C=(2,0) it puts you at f=(2,-1) which normalizes to F=(5,0).  But
> to travel "backwards" from F to get to C is north, not south as it would
> be if the map was always well-oriented.  I'm pretty sure this will give
> problems with some parts of the code, particularly goto code.
> 
>>From a user's point of view there are problems, however.  Back when we
> discussed approximations of a sphere I remember considering a wrapping
> like this, since it is the obvious way to simulate a pole. 
> Unfortunately it breaks down since the wrapping itself is not symmetric,
> as I described above.  A unit at A will witness a different type of
> wrapping than a unit at D will.  In fact what a player at D will see is
> a singularity, since tile D borders itself.  This presents a roadblock
> that isn't fatal, but will probably prevent it from ever gaining
> widespread acceptance.
> 
> jason
> 
> 
>