Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: [PATCH] check_map_pos change (PR#1031)
Home

[Freeciv-Dev] Re: [PATCH] check_map_pos change (PR#1031)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [PATCH] check_map_pos change (PR#1031)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 30 Oct 2001 10:46:14 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Oct 29, 2001 at 07:57:41PM -0500, Ross W. Wetmore wrote:
> IS_BORDER_MAP_POS is actually incorrectly implemented for what it
> is doing. Maybe it would help if you thought of it as the inverse
> of IS_INTERIOR_MAP_POS. 
> 
> Interior tiles do not need to check normalization in adjacent loops, 
> only tiles on the border or outside can cause problems, at least
> until someone introduces random unreal tiles.
> 
> And the check_pos() does not make a lot of sense here. 

> It is actually quite reasonable to do an adjacent loop from a
> position outside the map.

From Gaute's email:
> As has been mentioned a couple of times already, the idea is to find
> bugs.  We are aiming for a model in which all functions should produce
> / expect normalised coordinates unless there is a very good reason why
> not.  So if we pass unnormalised coordinates to a funtion / macro,
> that's a bug; and we want to know about it.

So what reason should have a iterate loop to start at an unreal map
position? If there is such a case we can soften the restriction. Till
than I would like to enforce that the iterate macros are only called
with a normal position.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "That's fundamental game play!  My main enemy is *ALWAYS* fighting 
  a 4-front war.  I make sure of it!"
    -- Tony Stuckey, freeciv-dev


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