Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: Gaute B Strokkenes <gs234@xxxxxxxxx>
Date: Thu, 16 Aug 2001 22:45:47 +0200

On Thu, 16 Aug 2001, jshort@xxxxxxxxxxxxx wrote:

> 1.  The only reason to make these functions macros is speed.  Speed
> is a small concern compared to the possibility of having multiple
> topologies.

Don't belive everything you're told on freeciv-dev.  8-) As it stands
now, the possibility of having multiple topologies is in no way, shape
or form related to whether or not it is feasible to use a macro here.
The only case in which I can even see a macro possibly not being
adequate is if we ever implement `isometric view' shapes, and even
them I'm doubtful.  In any case, you would have to change so much code
to implement that (including rewriting is_real_tile() from scratch)
that the 30 seconds that it will take you to search and replace
IS_REAL_TILE() -> is_real_tile() is the least of your worries.

> 2.  I think we have some confusion over the meaning of "normal".  I
> don't see how the coordinates (2, -1) could possibly be normal.  I
> don't understand the difference you claim between "normal" and
> "proper" coordinates.  If you're saying they're "normal" because
> they can't be wrapped to anything, then...it's a nomenclature
> problem.  We should agree on a name (normal or proper, whatever),
> and use that.  I don't see how the macro IS_NORM_TILE you describe
> would ever be useful.

That really shouldn't be hard.  There are several places in which we
wish to adjust an x coordinate if it is out of bounds.  For reasons
that have been elaborated elsewhere, it is not considered good to look
only on the x coordinate when deciding whether to do so, so you use a
macro like IS_NORM_TILE() to do it.  If you had used IS_PROP_TILE()
instead, the x coordinate would only be adjusted if the y coordinate
is within bounds.

Now you might argue that since it's not a real tile then you don't
care anyway, and you would be half right.  However, I'd be willing to
bet good money that somewhere along the line you would expect that x
coordinate to be reasonable and be surprised when it isn't.

Basically, IS_NORM_TILE() is what you ask when you wish to know the
answer to the question "Do I need to to adjust these coordinates so
that they are sensible?", and IS_REAL_TILE() is what you use to answer
"Did I just step over the edge of the world, or what?".  Note that
these are two different questions.  It is sloppy to treat them as the
same; and sloppiness will always come back to haunt you, one way or
another.

> Note that my definition of is_normal_tile corresponds very closely
> to normalize_map_pos.

That's a bug in normalize_map_pos(), if anything.  Note that there is
code which duplicates the normalisation code on a failed call to
normalize_map_pos().  My feeling is that this is just an optimisation,
since it was probably felt that `if it's not real then you don't need
to know what it is'.  That doesn't apply to IS_*_TILE().

> Using normal to mean something else would be _very_ confusing IMO.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
An air of FRENCH FRIES permeates my nostrils!!


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