[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sun, Apr 13, 2003 at 05:37:59PM -0500, Jason Dorje Short wrote:
> >>This is a clever(ish) way to define an operation on "native" coordinates 
> >>that really uses map coordinates.  Unfortunately, in addition to 
> >
> >>being extremely inelegant
> >
> >I disagree. It is one place less which is topology dependent.
> 
> Actually it is one more place which is topology dependent - since this 
> (DIR_DX/DIR_DY) would not otherwise be a topology-dependent operation. 
> The only places that care whether the topology is isometric are 
> native_to_map_pos, map_to_native_pos, and the mapview window-clipping 
> function.

If I have to choose if either adjc_iterate and square_iterate or
MAPSTEP are topology dependent I will choose the latter.

> >>Additionally, you are defining map directions in terms of map
> >>coordinates, rather than native coordinates - even though you
> >>propose to remove map coordinates from the code.
> >
> >In the current code everything is a map coordinate. Map coordinates in
> >your proposal are similar to the effective form in my proposal. My
> >coordinates however are similar to your native coordinates.
> 
> In the current code everything is a map and a native coordinate, since 
> the two are identical for non-iso maps.  The effective form in your 
> proposal is equivalent to native coordinates.

Yes.

> >>If the directions don't even line up with your map, how is anyone
> >>supposed to understand what's going on?
> >
> >I think it is easier to understand one set of coordinates where
> >MAPSTEP does a magic thing as multiple sets of coordinates.
> 
> The problem is (1) the set of coordinates is itself very non-intuitive 
> and (2) the hacks you have to do to get local operations to work are 
> error-prone and non-intuitive.  Better to introduce a single, 
> freeciv-wide solution that is easily understandable (explained in 
> doc/HACKING) and works for everything.

There are certain parts of the code which are topology
dependent. These parts are few:
 - neighborhood relation: can be reduced to MAPSTEP
 - distance: is reduced to map_distance_vector
 - wrapping/normalization: is reduced to normalize_map_pos
 - mapview: is reduced to one file (mapview_common) AFAIK

So I propose that we change these 4 very isolated pieces of code and
don't confuse the general programmer with this. I'm not against doing
a transformation to a nicer coordinate system in these pieces of code
if this makes the task easier. But these "special task" coordinates
will never leave this functions (or file).

I'm also for defaulting to the other coordinate system (native and not
your new map coordinates). I think that most of the functions are
using these (no need to transformation for tile access). And from the
4 pieces above MAPSTEP and normalize_map_pos can be done as fast as
the current code. And MAPSTEP and normalize_map_pos are the most
common of the above functions. So I think that using native
coordinates is a speed win.

> >>Note, all of these are trivial if you are simply willing to do them
> >>in map coordinates.
> >
> >Yes. But you don't have to scare people by introducing multiple
> >coordinates (you have scared and confused me) and if these are only
> >used in one function (map_distance_vector). square_iterate and MAPSTEP
> >can be easy done without them as outlines before.
> 
> My original patch requested feedback on the explanation it provided in 
> doc/HACKING.  Perhaps we should start this discussion over, and you can 
> tell me what scares/confuses you.

While I still think that my idea should be done I will answer this
question. Completely missing is a "Gentle introduction to
iso-maps". Basics, requirements and semantics. All this that I had to
research by myself in the last days. Note that this is also needed for
my plan. But then only for the implementors of the 4 pieces of code
outlines above. So it is a _bit_ less required.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "When C++ is your hammer, everything looks like a thumb."
    -- Steven M. Haflich