[Freeciv-Dev] Re: RFC: alternate topologies

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 09, 2001 at 04:17:55PM -0400, Jason Dorje Short wrote:
> Raimar Falke wrote:
> > > - 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).

Where is this needed? To only case I can think of is the
right-center-map-click. In the other cases you want the user to click
on a "good" tile or forget about it.

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

Some of the changes (assumption that the map wraps in e-w directions
only) don't need the isometric map to provide a real enhancement.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Understanding is a three-edged sword; 
  your side, their side, and the truth."
    -- a well-known Vorlon