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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Raimar Falke wrote:
> On Sun, Apr 13, 2003 at 05:37:59PM -0500, Jason Dorje Short wrote:
> > > > 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
None of these are topology-dependent under map coordinates.  So in 
essence you are saying that these are the only parts of the code that 
need map coordinates.  But there may be more; I'm not sure.  Certainly 
there are some additional (non-mapview-specific) ones in mapview.
Conversely, if we use map coordinates as standard there are just a few 
places that need to convert to native coordinates.  These include a few 
map.c backend functions (normalize_map_pos, map_distance_vector, 
rand_map_pos, map_to_index_pos, index_to_map_pos) as well as a very few 
pieces of user code (savegames, map debug output).
>  - mapview: is reduced to one file (mapview_common) AFAIK
Don't just lump in everything in mapview.c and mapview_common.c into 
"mapview" and write it off.  mapview does have some very specialized 
needs (like clipping the window), but also some generalized ones as well 
(like rectangle_iterate).
> 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.
This is a reasonable position - using native coordinates as standard and 
only using map coordinates for needed operations.  The question one 
would have to answer is: how much harder is it to do this than to use 
map coordinates as standard?
> > > > 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.
Hmm, ok.

(I still don't see why you believe your method requires fewer code 
changes.  This may be true, but there is no evidence for it.)
jason