[Freeciv-Dev] (PR#7304) iso-map support for mapgen

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7304 >

> [rwetmore@xxxxxxxxxxxx - Tue Jan 27 03:15:14 2004]:

> In all the above cases these are property lookups where the lookup is made
> at a particular location (aka tile).
> 
> There should be one API for returning each property from a tile.
> 
> There may be many ways to find a tile given various coordinates, thus one
> would always write something like
> 
>    nat_get_tile(xn, yn)->get_terrain()
>    map_get_tile(xn, yn)->get_terrain()
> 
> If there are 10 properties like terrain, unit_list, printable
location, ...
> for each tile and 5 different coordinate systems for finding a tile,
> then rather than 5 x 10 = 50 APIs, you have 5 + 10 = 15 to worry about.
> 
> If you add a new property, you don't add any new coordinate APIs, and
> if you add a new coordinate system, you don't add any property lookups.

A reasonable argument.

Unfortunately the current API is all in map coordinates.  To do this
properly the API would have to be in tile or perhaps index terms, since
they are at a lower level - and, more to the point, 1-dimensional.  We
can't do

  map_set_special(native_to_map_pos(nx, ny), S_RIVER);

but we could do

  index_set_special(native_pos_to_index(xn, yn), S_RIVER);

or

  tile_set_special(nat_get_tile(xn, yn), S_RIVER);

The last is clearly the cleanest form.  However doing it this way
requires addional functions in map.h - more than the 2 that are required
for the direct form.

So I would see this as a long-term design goal rather than something to
target in this patch.  But I'd be happy to code it the other way if
others disagree.

(Note that we don't want to do

  nat_get_tile(xn, yn)->special |= S_RIVER

since map_set_special has side effects, even though they happen to not
do anything in this case.)

> >>Where would you ever want to really use the map coordinates, apart from
> >>adjacency calculations which can be hidden in few macros?
> 
> These are the original server core coordinates for Freeciv, which are
> exactly what you see in the original standard Earth map topology. The
> neighbour relationships are geometrically precise which means that apart
> from rotation/translation, they look like you would expect as a naive
user.

This is a misleading statement.  Native coordinates are also the
original server core coordinates, since under orthogonal maps native and
map coordinates are equivalent.  Only by our definition (or lack of
rigorous definition) has "map coordinates" come to mean the cartesian
set of coordinates.

Note that in a hexagonally-tiled map "map coordinates" would be much
less useful.  Native coordinates could still exist, but map coordinates
would not line up directly with the cartesian visualization.  In fact
there is no way to put a hexagonally-tiled map into cartesian
coordinates, using only integers.

P.S.  I think "cartesian" coordinates is a good term for what we now
call "map" coordinates.

> In a similar fashion to the 5 x 10 argument above, they are also the
> common coordinate system that all other coordinates must be able to
> convert to and from. Thus one can always convert between arbitrary
> coordinates with at most two steps going through map coordinates.
> There are (n-1) such conversion functions as opposed to n x n.

Also misleading.  We could just as easily use any other form for this.

> >>In future, when compiled with DEBUG option, which coordinates will
> > clients 
> >>display on middle-click?  They should be map coordinates (because such 
> >>things are used to locate units for debugging), but these would be very 
> >>hard to find on a map!
> 
> This is something to be debated and agreed upon.
> 
> It probably makes sense to be one of te GUI coordinates that mean
something
> in one of the *_view windows.

These values are of no use to the player - they are only of use to
debuggers and allow comparison to log messages.  So the form that is
used must correspond to what freeciv uses for logging.  Currently that
is map coordinates.

Of course, since they're only useful for debugging it would probably be
helpful to show the position in multiple forms - map and native
certainly; possible index and GUI positions as well.

jason