Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: RFC: alternate topologies
Home

[Freeciv-Dev] Re: RFC: alternate topologies

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: RFC: alternate topologies
From: Jason Dorje Short <vze2zq63@xxxxxxxxxxx>
Date: Tue, 09 Oct 2001 19:53:00 -0400
Reply-to: jdorje@xxxxxxxxxxxx

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

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

jason


[Prev in Thread] Current Thread [Next in Thread]