Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2004:
[Freeciv-Dev] (PR#7350) Map radius change with city size
Home

[Freeciv-Dev] (PR#7350) Map radius change with city size

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: remi.bonnet@xxxxxxxxxxx
Subject: [Freeciv-Dev] (PR#7350) Map radius change with city size
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 16 Apr 2004 11:10:23 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7350 >

> [rwetmore@xxxxxxxxxxxx - Sat Apr 10 05:03:40 2004]:

> The advantage of doing it in general iteration is that usually a
> closest tiles first order is going to find the optimum whatever
> over an array order iteration. These effects are actually part
> of the reason why the corecleanups consistently ran 50% faster
> than comparable CVS. The fact that you forced the core DIR_DX
> handling to be the same as the GUI, rather than using rotational
> order in the core and array order only for GUI tiling is a similar
> case to this more limited citymap example.
> 
> Thus doing things in the order you argued for and chose by getting
> in a partial patch back then, i.e. link the two, then migrate,
> rather than keep the core and GUI separate and migrate just the
> core leaving the GUI for a proper overhaul, has had signficant
> and detrimental results. We are now at the point where the GUI
> is being cleaned up with a separate set of coordinates, but the
> unnecessary linkages and performance/robustness/simplicity
> cleanups are still not done. And you are still fighting them now
> with O(5) patches that still handle things from the array order
> perspective.

On the topic of the direction8 ordering...

enum direction8 is just a list of directions.  Nobody (not the GUI or
the core code) needs this to be in any particular order so long as they
use the correct interface (including DIR_REVERSE, dir_cw, etc.) for
manipulating the directions.  Rotational ordering is faster for some
operations, like dir_cw, which are currently used only by the GUI.  It's
also more elegant, meaning fewer lines of code in these functions.

Changing the ordering meant fixing all of the users to use the
interface.  The only reason you wanted to separate the GUI from the core
ordering was because you didn't want to bother to clean up the GUI code.

AFAIK there's nothing preventing us from reordering the directions now.
 However if it's just a question of speed, I suspect the rotational
ordering will end up making the server slower.

As an aside, nobody who actually played the corecleanups would claim
that they were faster than CVS code.

jason



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