[Freeciv-Dev] Re: Map coordinate cleanups.

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

Trent's diagram and thoughts make for an intriguing puzzle, and your
suggestions are an interesting avenue to explore for implementation.

At the moment, though I don't see an obvious way to take care of a lot
of endemic assumptions in code that assume a coordinate move is valid
in many rectangularly based ways even if they are getting to the point
that they won't execute (politely as opposed to catastrophically) if 
told the move is bad.

If is_real_tile and normalize_map_pos could give "correct" answers for
a transition, i.e. not just (4.3) is valid and points to tile (2,3),
but it points to tile (4,5) if you are going the other way, or something
like that, then a lot of things are much more possible. In my feeble
attempts to mentally pin down the gut feeling, it might be that you 
need a ring of border tiles or tile positions that get transformed into
one or more alternate coordinates when normalized based on how you 
moved into them. So, moving west into such a tile would take you to a 
different place than moving north into it. Of course the API for these
doesn't have the extra "starting location" information, yet. MAP_STEP
if it became the defacto way to get coordinates might be able to handle
this better,

But my head hurts when I think of this, and we still haven't got the 
simpler coordinates into the system yet, so I definitely want to punt
on this for a week or two :-).

Cheers,
RossW
=====

At 07:12 PM 01/08/18 -0700, Kevin Brown wrote:
>Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote:
>> On Sat, 18 Aug 2001, Gregory Berkolaiko wrote:
>> > > You have basically understood everything.  The only thing that I have
>> > > to add is this: normalization is independent of realness.
>> > 
>> > IS_WRAPPED = wrapping rules applied but not necessarily real
>> 
>> 
>> As others (Ross?  David?) have pointed out, the purpose of wrapping
>> coordinates is to discover which real tile they refer to.  If coordinates
>> do not refer to a real tile, then they cannot be wrapped in a meaningful
way. 
>> It might appear that if you wrap the X coordinate around and leave the Y
the
>> same, you have wrapped a non-real coordinate, but that's just an illusion.
>> 
>> 
>> Consider a diamond shaped map that's supposed to play like a sphere:
>> 
>> X    0  1  2  3  4
>> Y
>>           +--+
>> 0         |  |
>>        +--+--+--+
>> 1      |  |  |  |
>>     +--+--+--+--+--+
>> 2   |  |  |  |  |  |
>>     +--+--+--+--+--+
>> 3      |  |  |  |
>>        +--+--+--+  
>> 4         |  |
>>           +--+    
>> 
>> Coordinates wrap around the east and west edges, but not the north
>> and south.  For example, (0,1) would wrap around the edge to (3,1),
>> and (-1,2) would wrap to (4,2).  What would the coordinate (4, -1)
>> wrap to?  Since it's a not a real coordinate, there is no meaningful
>> way to wrap it.  The cylinder topology just creates the illusion
>> that it is possible to wrap non-real coordinates.
>
>This gives me an interesting idea.  I haven't really looked, so if
>it's already implemented then slap me.  But:
>
>If we set up the code so that you can define a map with intentionally
>"unreal" locations (with such a location represented, say, by a space
>character), then you should be able to get all sorts of interesting
>topologies (well, crude approximations of them, anyway) out of it with
>relatively simple wrapping rules.  Maybe.  I'm trying to come up with
>a simple way of going from real tile to real tile when wrapping
>through unreal tiles and which behaves as you'd intuitively expect
>(more or less).  Going N/S/E/W is easy, I think: you wrap around that
>direction until you hit a real tile, and that's where you land.  The
>question is what to do for diagonal moves, and I haven't figured out
>that one yet.  I'm tempted to say you should move to the unreal tile
>then move in one component direction (e.g., N or E if the move was NE)
>until you hit a real tile.  The component direction you use is
>whichever gets you onto a real tile in the shortest map distance (so
>unreal tiles count for the distance) in the component direction, or a
>preferred component direction if they're equidistant".  But I'm not
>sure how well that would really work.
>
>
>Hmm...maybe this isn't such a good idea after all.  :-(   What do you
>guys think?
>
>
>
>-- 
>Kevin Brown                                          kevin@xxxxxxxxxxxxxx
>
>    It's really hard to define what "unexpected behavior" means when you're
>                       talking about Windows.
>
>