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

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Raimar Falke wrote:
> On Tue, Apr 08, 2003 at 11:03:59PM -0500, Jason Dorje Short wrote:
> > Raimar Falke wrote:
[...]
> > But I think you have not thought through things fully.
> That is quite possible. I'm still trying to understand.
>
> > How would you implement:
> >
> >  - square_map_iterate
You decide what you want square_map_iterate to do. With the "map"
in the name I presume you want this to run in map coordinates, and
thus it would be a local 3x3 square just like it is now. This makes
it compatible with adjacent_iterate when you need the center. In an
iso view this would appear as a rhomboid or diamond shape, i.e. a
square rotated pi/4.

But if you want a block_iterate for dealing with rectangles oriented
along the natural map axes as in defining the polar regions of the
map, or something that iterated over a region of constant radius with
efficient wrapping across map edges, you would do it in native coordinates
and probably call it (block/square)_native_iterate().

Since there are reasons for having both, you would probably look at
the current code and decide whether it was a local or global operation
and use the macro that was appropriate.

The important thing to remember is that many operations are muddled
in the current code which was never written to deal with general
topologies, just a simple rectangular map window where the same
coordinates are the right ones for multiple contexts.

But even true isometric which changes the orientation of the natural
map axes to be pi/4 rotated wrt the internal standard map ones starts
to break down some of these symmetries and thus requires you to think
about the real context in each case. map_view complexities with all
kinds of ugly special case code are the result of doing things in one
coordinate system which happens to be the wrong one in half the cases.
Note, *only* map_view is ugly now because the current code does not
handle true isometric maps, and only provides an iso view of a
standard rectngular map.

In most spots updates to generalize the core code involve trivial code
changes.

What native does is provide an easy context for the global operations,
while internal map coordinates deal with local ones. Most of the inner
code is of the local variety so most of this code is never touched. The
outer loops often contain a global iteration, and thus you loop in
native coordinates and provide a conversion at the top of the loop
to map coordinates. Since the global loop in the current code is
equivalent to native for its limited topologies, the actual code
doesn't change except to rename the loop variables and provide the
conversion line. Once you have done this, you have genralized the
core and all topologies just work.

[...]
> > it's not just a question of how many places need to be touched, but of 
> > how difficult/ugly/unmaintainable the new code will be.
The code is actually simpler using native coordinates where they are
best and map coordinates where they are best - by definition really.

You may have to learn to live without the current quota of ugliness
and unmaintainability when all is said and done :-).

[...]
> Also I think that in my idea I want to make your native coordinates
> the "normal" "map" coordinates.
I know, you always choose this anti-pattern as your first approach.
Try to understand that one size does not usually fit all cases.

Apply it in this case by understanding what the separation really is
that is being done and why thinking in two coordinate systems makes it
easier to deal with problems by choosing the one that is most
appropriate for each.

This is already done for memory operations vs map operations. Map
operations are handled in a 2-D rectangular system, while memory is
handled as a linear 1-D vector. One converts, or the compiler converts
2-D to 1-D offsets and back all the time.

>         Raimar
Cheers,
RossW
=====