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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<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;
> > 
> > It's been tested moderately with a variety of generators and topologies.
> >  However there are a very high number of possibilities so it's possible
> > some bugs remain (usually these bugs lead to an immediate segfault and
> > so are easy to find).
> 
> It looks sane to me.  Minor requests:
> 2. We should agree on a policy where the name of a coordinate would 
> indicate its type.  I am really aginst things like
>       native_to_map_pos(&x, &y, x, y);
> It seems the default is map coords, so native should _always_ be called 
> (xn, yn).

OK.  I've generally been using map_x,map_y and nat_x,nat_y but when
these are too long I fall back to x,y.  But you're right.

> 3. I don't understand the need for the extra layer in do_in_map_pos.  Is 
> it to const the variables?

Yes, just to const the variables.

> 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.  
> Where would you ever want to really use the map coordinates, apart from
> adjacency calculations which can be hidden in few macros?
> 
> 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!

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.

jason