All of the code examples above are in map coordinates. These preserve the local geometry of square tiles, but do not represent the global map geometry well. In map coordinates, you are guaranteed (so long as we use square tiles) that the tile adjacency rules
(map_x-1, map_y-1) (map_x-1, map_y) (map_x-1, map_y+1) |
(map_x, map_y-1) (map_x, map_y) (map_x, map_y+1) |
(map_x+1, map_y-1) (map_x+1, map_y) (map_x+1, map_y+1) |
are preserved, regardless of what the underlying map or drawing code looks like. This is the definition of the system.
Map coordinates are easiest for local operations (like square_iterate or adjc_iterate) but unwieldy for global operations.
With an iso-rectangular map, global operations are difficult using map coordinates. Imagine a simple iso-rectangular map. Its "natural" representation is
A B C D E F G H I |
(0,0) (2,0) (4,0)
(1,1) (3,1) (5,1)
(0,2) (2,2) (4,2)
|
while its representation in map coordinates would be
CF BEI ADH G |
(2,0) (3,0)
(1,1) (2,1) (3,1)
(0,2) (1,2) (2,2)
(1,3)
|
Neither is particularly good for a global map operation such as whole_map_iterate. Something better is needed.
Native Coordinates[]
Native coordinates compress the map into a continuous rectangle; the dimensions are defined as map.xsize × map.ysize. For instance the above iso-rectangular map is represented in native coordinates by compressing the natural representation in the X axis to get the 3 × 3 iso-rectangle of
ABC DEF GHI |
(0,0) (1,0) (2,0) (0,1) (1,1) (2,1) (0,2) (1,2) (2,2) |
The resulting coordinate system is much easier to use than map coordinates for some operations. These include most internal topology operations (e.g., normalize_map_pos, whole_map_iterate) as well as storage (in map.tiles and savegames, for instance).
In general, native coordinates can be defined based on this property: the basic map becomes a continuous (gap-free) cardinally-oriented rectangle when expressed in native coordinates.