[Freeciv-Dev] Re: (PR#7287) Extended Topologies

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

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


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
[...]
> I think what Ross is talking about is a reverse-wrap with a half-map 
> offset.  So you have
> 
>    pqr-mno pqr-mno pqr-mno
>    jkl-ghi jkl-ghi jkl-ghi
>    def-abc def-abc def-abc
>    abc def-ABC DEF-abc def
>    ghi jkl-GHI JKL-ghi jkl
>    mno pqr-MNO PQR-mno pqr
>    pqr-mno pqr-mno pqr-mno
>    jkl-ghi jkl-ghi jkl-ghi
>    def-abc def-abc def-abc
> 
> We've considered this wrapping before but decided it was invalid.  I 
> don't remember why.  Note that in 3 dimensions this can't be done as a 
> sphere (it can be done as a torus with extra congruencies), but in 2D it 
> looks okay...
> 
> jason

I'm not sure who considered it and definitely don't remember it being
termed invalid in any posting, but there are some problems with the
various views that can be solved, but would need changes along the lines
of the hemisphere model or the like.


One of the problems with projecting a spherical Earth onto
a 2-D torus-world through an intermediate mapping to a real
torus, is how to scroll the GUI window.


As a simple starter example, consider an overview holding a
single normal set.

If the initial position is a standard Mercator projection
with the Grenwich meridian in the centre, then there is no
issue with E-W scrolling. This is the original Freeciv
standard map, afterall.

But if one scrolls N-S, then the next line of tiles coming
onto the map along the northern edge is already on the map
allbeit shifted E-W by half a map width. The line dropped
at the bottom is now no longer on the map anywhere.

This problem arises because of the non-simple wrapping at
the polar lines and the fact that there are really two
classes of normal set in the super-tile of the map.


How does one fix this?

There are two immediate solutions that come to mind.


In the first, one designs the overview a little differently
and constructs it as two maps one representing each hemisphere.
For simplicity, assume the primary hemisphere which designates
the location of the active unit of tile is on the left and
initially centred on the Grenwich meridian. The secondary or
hidden hemisphere is on the right and centred on the dateline.
For starters the equator runs through the middle of each and
thus the overview is just an E-W rotation of the standard map
with a user visible break down the centre between each half.

Now scroll the primary N-S as above. The secondary then scrolls
in the *opposite* direction, so that the line that enters on the
top of the primary, leaves on the top of the secondary. Similarly
at the bottom, the line dropped from the primary enters as the
new bottom line on the secondary.

Ok, now what happens when you scroll E-W. The line that leaves
the primary in the centre will jump the centre and appear in
the secondary. The line leaving the secondary on the far right
will appear on the primary at the far left. *But* in so doing
they will roll in the N-S direction so the longitudinal lines
again match.

One can scroll N-S by half a map and get a reversed world
image everywhere. But one would probably do something like
flip the primary as the focus unit or tile crosses the poles
such that it always sits in a mostly normal primary window,
i.e. up at the focus tile always points to the north pole.


The second solution chooses a different normal set mapping for
the overview display. In this case, the two hemispheres are
stacked on top of each other with the secondary one attached
but inverted and rotated so that one can continuously scroll
in the N-S direction doing a polar orbit. Instead of breaking
the torus into inside and outside as above, one takes half a
donut as the displayed set.

E-W scrolling in this case causes a line to move off one side
of the map and invert/roll itself in a pseudo Jason strip
wrapping (pseudo because I don't think it flips through the
centrepoint).

Since one half of the map is always inverted, there is less
need to flip, but one probably still wants to have the focus
unit or tile always oriented such that up is towards the
north pole. But which half, top or bottom, is the primary
hemisphere display is also more fuzzy as one might just want
to have the focus tile in the centre and drop the hemisphere
concepts.


Now things get trickier. How should one deal with the canvas
map?

Note that it is fairly trivial to draw the surrounding bounds
of the canvas on the overview in either of the above cases.
The trick is to define the orientation of North. This may
in fact be linked to how one defines north in the primary
overview display. But if one doesn't have a primary hemisphere
concept, then this is much more dicey. Also, what happens
when the canvas is larger than half of any dimension, especially
in the hemisphere cases above. One can map the bounding box lines
to the various (odd) edge locations and copy the contents into
a rectangular canvas, but there will be some issues to work out
as the GUI grows even more.

Once one has worked out the above concepts from the user
perspective, the hard part comes in trying to figure out all
the mappings, what *THE* normal set is and the rest of the
implementation. Does one model things on an underlying full
or half torus as the map coordinate space, and which half
slice? If one chooses a half torus or basic normal set, then
the wrapping operations are going to be non-simple. If one
chooses a full torus, then one has to deal with the normal
subset issues when accessing a tile and the ambiguity of
having two coordinate positions map to the same location, or
rather what happens when you need to do the reverse mapping
from native to map. These are all doable, but non-trivial.


Cheers,
RossW
=====