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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Raimar Falke wrote:
> On Fri, Apr 04, 2003 at 07:48:14PM -0800, Jason Short wrote:
> 
>>This is a significant design issue, and should be closely scrutinized. 
>>I'd encourage everyone to at least read this patch.
>>
>>Native coordinates (sometimes called "compressed" coordinates in the
>>past) are a concept Ross came up with to make isometric (and other
>>non-standard) maps easier to deal with.  They save around 50% memory
>>(and on disk, in savegames) for map storage over "standard" map
>>coordinates and make topology operations *much* simpler.  Other
>>coordinate systems may share one of these properties, but none have
>>both.  In the process, they invalidate the need for "regular" map positions.
>>
>>The patch introduces native_to_map_pos and map_to_native_pos macros into
>>map.h, along with one very simple user.  I've also written an
>>explanation of the coordinate systems for doc/HACKING.  I'd like
>>feedback on this explanation, particularly from people who don't already
>>know what "native coordinates" are.
>>
>>All other explanation is in the patch (or if it isn't, it should be).
> 
> 
> What operations (would) require native coordinates? I have the feeling
> that a lot can be done with indexed coordinates. For example
> savegames.

True, storage (such as savegames and map storage) can be done either 
with native or index coordinates.  The goal here is 
backward-compatability; we might as well use native coordinates for 
savegames and indexed coordinates for map.tiles because that's 
(basically) what's done now.

Native coordinates are especially good (compared to map coordinates) for 
topology operations.  For instance normalize_map_pos can be written 
something like:

   #define WRAP(x, range) (x % range < 0 ? x % range + range : x % range)

   bool normalize_map_pos(int *map_x, int *map_y)
   {
     int nat_x, nat_y;

     map_to_native_pos(&nat_x, &nat_y, *map_x, *map_y);

     if (map_wraps_horizontally()) {
       nat_x = WRAP(nat_x, map.xsize);
     } else if (nat_x < 0 || nat_x >= map.xsize) {
       return FALSE;
     }

     if (map_wraps_vertically()) {
       nat_y = WRAP(nat_y, map.ysize);
     } else if (nat_y < 0 || nat_y >= map.ysize) {
       return FALSE;
     }

     native_to_map_pos(map_x, map_y, nat_x, nat_y);
   }

> AFAIK there is no sane way to represent an iso-map in the
> 2d layout we have in savegames?!

No, the iso-map

   X X X      XXX
    X X   <=> XXX
   X X X      XXX

can easily be represented in our 2d layout in the second (native) form.

> If this is true I would for example
> rather go with indexed coordinates in savegames and remove the 2d
> layout. If this is true the gamelog does have the same
> problem. Wouldn't it be better for the gamelog to use this
> representation
> 
> 
>>+      X X X
>>+       X X X
>>+      X X X
> 
> 
> ??

Slightly better, yes.  This is the "natural" representation.  But how 
are you going to get this output without special-casing isometric maps? 
  The native representation

    XXX
    XXX
    XXX

is almost as good, and (I think) much easier to use.  It can also be 
used for the map overview without any problems (a similar situation).

jason