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

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

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


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7304 >
> 
>>[Gregory.Berkolaiko@xxxxxxxxxxxxx - Sun Jan 25 19:48:22 2004]:
>>
>>On Sat, 24 Jan 2004, Jason Short wrote:
>>
>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7304 >
>>>
>>>Adding iso-map support to mapgen is an ugly task.  Here's the patch to
>>>do it.
>>>
>>>We must constantly be thinking about whether the positions we're working
>>>with are in map or native coordinates.  Mapgen must generally work with
>>>both.
>>>
>>>A few wrappers (suggested by Marcelo) are used for convenience:
>>>  nat_get_terrain => returns the terrain for a position in native coords
>>>  nat_set_terrain => blah, blah
>>>  do_in_map_pos(map_x, map_y, nat_x, nat_y) {
>>>    => mapgen macro to allow local conversion from native to map coords
>>>  } do_in_map_pos_end;

These wrappers are actually a bad way to go.

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.

[...]
>>Now, a big question.  I appreciate it's probably too late to ask it
>>and  that I possibly already asked it a couple of times.
>>
>>It seems that the default coordinates throughout Freeciv will be map
>>coordinates.  Why not native?  They are more "natural" for most things. 

Actually, native are not particularly natural. They are designed to make
an efficient rectangular grid for 2-D output to savegames and debug print.
The use of compressed iso coordinates for iso-native is not particularly
intuitive as a general user coordinate.

>>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.

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.

>>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.

> Something like this is possible and _may_ be easier or faster.  But it
> will require a lot of auditing of the code.  Any place which fiddles
> with coordinates locally (and there are a lot) needs to do this in map
> coordinates.  So at a minimum it will require lots of auditing.
> 
> First of all, I think the term "map" coordinates is pretty generic. 
> This term should just refer to the default coordinate system.  So we
> have native coordinates and also (what I will call) "tile" coordinates.
>  We could have completely separate interfaces for each:
> whole_tile_iterate versus whole_native_iterate, with whole_map_iterate
> being defined to the current default coordinate system.  This is
> overkill, but you see the idea.  (We also have index coordinates, which
> are easiest for some operations to work in.)  The problem is there are a
> lot of functions that operate at a low level on coordinates, and they're
> not particularly separated from the rest of the "map" code - so even
> getting the interface right would take some work.
> 
> Of course, I haven't tried any of this.

A little fuzzy, but none of the ideas are too far offbase. I think once
one gets a more concrete feeling for what coordinates are and where they
should be used, these things will fall out pretty quickly.

A key idea is that coordinates should not be central to everything, but
for example only used to locate or compute geometric parameters for or
between objects that have a location property. This might mean GUI pixels
or core game mechanics, but each coordinate (system) should have a well
defined use and set of interactions with the rest of the world.

A proper answer to Gregory's question is a starter on this.

> jason

Cheers,
RossW
=====