[Freeciv-Dev] Re: RFC: alternate topologies

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Raimar Falke wrote:
> 
> On Tue, Oct 09, 2001 at 03:33:24PM -0400, Jason Dorje Short wrote:
> > Here is the proposal, in full (version 1, pretty informal).
> >
> > 1.  Mathematical Definition of a Allowable Topology
> >
> > Any topology which fits the following informal definition should work
> > with the proposed changes.
> >
> > - Definitions:
> >   - Let Z be the set of all integers.
> >   - A "position" is the same as a "coordinate set".
> 
> A set isn't ordered.

Correct.

> >   - A "tile" is the same as a "position" but should not be used.
> >
> > - S=ZxZ is the set of all possible positions, both real and unreal.
> >
> > - R<S is the set of all "real" or "valid" positions.  (< means subset
> > here).  Any position that is real has at least the following properties:
> > (1) units can move there (2) the client can draw a tile for that
> > positions.  An unreal (not real) position does not have these
> > properties.
> 
> (2) is wrong if we allow the client to only draw a tile one time.

Good point.  It's a bad example.


[snip snip]

> > - nearest_real_pos(&x, &y) adjusts x and y to be one of the nearest
> > positions to (x, y) that is contained in N.  (NOTE that it is misnamed,
> > it should be nearest_normal_pos.)  Since distance is poorly defined and
> > there may be more than one position with equal distance, the new set of
> > coordinates is not well-defined.  Thus you should not assume anything
> > about this function.  It is definitely needed to keep the same behavior
> > in the user interface, unfortunately; in fact right now it is the same
> > as x=map_adjust_x(x),y=map_adjust_y(y) which is still used in many
> > places (mostly incorrectly).
> 
> Grepping through the current source I think that nearest_real_pos
> should be removed. In short time. There are currently no valid uses of
> this function.

There is one use for which I originally proposed it: if in the client
you click on an unreal tile, this is converted to a real tile.  So
clicking on (20, -1) currently would convert the click to (20, 0) using
map_adjust_y.  For arbitrary topologies this must be a separate function
(unless you want to loop looking for a real tile, which would be very
ugly).

> > - map_pos_difference(x1, y1, x2, y2, &dx, &dy) will determine the
> > minimum difference between (x1, y1) and (x2, y2).  The (dx, dy) are the
> > x and y differentials of the two positions; "minimum distance" is
> > defined as having a minimum (max(dx, dy)).  If more than one position
> > has equal minimum difference, the result may be any of the equivalent
> > differences.
> >
> > - A few other functions may also be needed.
> >
> >
> > 4.  Necessary Changes
> >
> > A lot of current code assumes that the topology is flat-rectangular and
> > wraps in e-w directions only.  This code must be fixed.
> 
> This is a non-isometric cleanup/enhancing.

I don't quite understand this sentence.

Most or all of these changes are necessary for an iso-rectangular map,
but in general they're targeted at the more general case outlined in
part #1.

> > - Anything that loops over tiles and assumes every tile within a
> > rectangle is on-map (normal) is bad.  The fix generally involves
> > checking for is_normal_map_pos and skipping those which are not proper.
> 
> for loops:
> 
> $ grep -Irc 'for.*map..size' .|grep -v :0
> ./client/goto.c:1
> ./client/gui-mui/overviewclass.c:2
> ./common/game.c:12
> ./common/map.h:2
> ./server/barbarian.c:2
> ./server/gamelog.c:2
> ./server/mapgen.c:15
> ./server/maphand.c:3
> ./server/savegame.c:88
> ./server/gotohand.c:4

Yeah, there are a fair number of them left.  Most are in savegame.c
which is what we're dealing with first.

jason