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