| [Freeciv-Dev] Re: RFC: alternate topologies[Top] [All Lists][Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
 
 On Tue, Oct 09, 2001 at 07:53:00PM -0400, Jason Dorje Short wrote:
> Raimar Falke wrote:
> > 
> > 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.
> 
> That may be all.
> 
> Do you think we should drop it?  It's fine by me...
But even this one isn't the issue. Since you can just center on the
drawn unreal tile. However I would wait with the removal of
nearest_real_pos till we removed all map_adjust_* calls from client/.
> > > 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.
> 
> Ahh, yes.  Unfortunately these are the hardest changes I think.
        Raimar
-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Windows: From the people who brought you edlin...
Message not available
 
 |  |