[Freeciv-Dev] Re: Map coordinate cleanups.

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

I take back the comment about is_real_tile() and normalize_map_pos() not 
having the capability to handle directional coordinate transformations.

GUI people will better understand the implications of this, but the 
"trick" to doing this with the current (x,y) arguments is to add an extra 
bit to each coordinate that basically says which side of the tile you
want the transformation for. 

This has the effect of changing a single tile into 4 subtiles, each of 
which can have its own "wrapping" transformation. The reason why I think
GUI people might understand is that this is just a pixel scaling into
4 new ones, and they have probably thought about how to count and work 
with scaled positions.

If tile lookups go through map_get_tile() or its equivalent, this one
spot can be modified to deal with converting subtile coordinates to true
tile coordinates, and a lot of the local iteration macros can catch
many of the other cases. My guess is that 90% of the codebase would fall
out with a few lines of change. The difficulty will be rooting out the
last 10% and updating any explicit code algorithms that don't use the
standardized tools.

Cheers,
RossW
=====

At 12:53 PM 01/08/19 -0400, Ross W. Wetmore wrote:
>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.
>>
>>
>
>
>