Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: [PATCH] Map cleanups (PR#1208)
Home

[Freeciv-Dev] Re: [PATCH] Map cleanups (PR#1208)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] Map cleanups (PR#1208)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 08 Jan 2002 00:24:15 -0500

At 12:53 PM 02/01/07 +0100, Raimar Falke wrote:
>On Mon, Jan 07, 2002 at 01:18:57AM -0800, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
>> Ross W. Wetmore wrote:
>> 
>> > At 03:45 PM 02/01/06 +0100, Raimar Falke wrote:
>> >>On Sun, Jan 06, 2002 at 04:32:02AM -0800, jdorje@xxxxxxxxxxxxxxxxxxxxx
wrote:
>> >>>Ross W. Wetmore wrote:
>> 
>> The "side effects" are that x and y are changed if they are real and 
>> non-normal.

I'm somewhat strongly against the "side effects" even with a smiley. 
This is of course the primary function of normalize_map_pos(), to 
normalize real but unnormal positions.

>>  I am in favor of making normalize_map_pos _not_ change x 
>> and y if they're unreal (as you say, some parts of the code assume 
>> this), but against making it a defined part of the interface.  But I 
>> don't think it's a sticking point; we'll call this a skirmish.
>
>Ok I now understand what Ross wants. So this looks like we have to
>review all normalize_map_pos calls.

All current normalize_map_pos(0) calls should be ignoring the return
values in the unreal case since the time that Gaute broke it. It was 
once ok to assume they were untouched, and thus GUI code could use
them for black tile stuff. 

I think it still works even with the breakage because, I don't think 
Gaute converted unreal to real, just to some (arbitrary) other unreal 
position. But if people start nearest_real_pos conversion all hell 
will break loose, because it *does* do really bad void_tile things.

Fixing it here by making this condition part of the interface, means 
any cases that were missed are now ok, as the interface is defined to 
*not* touch unreal coordinates now. 

Incidentally it doesn't touch real and normal ones either if properly 
coded.

Of course normalize_map_pos() *alwasy* normalizes real but unnormal
ones when it returns true, because that is its primary function.

>       Raimar
>
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "Any sufficiently advanced technology is indistinguishable from magic."
>    -- Arthur C. Clarke




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