Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2370) Path finding

[Freeciv-Dev] Re: (PR#2370) Path finding

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: "Per I. Mathisen" <per@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Wed, 19 Feb 2003 17:32:10 +0100

On Wed, Feb 19, 2003 at 09:28:49AM +0000, Gregory Berkolaiko wrote:

> Attached is my attempt to minimize the interface.  Not hugely
> successful.  If you can see what else can we ditch, please point it
> out to me.  I think we can get rid of get_TB, since get_cost
> callback can absorb it easily.  It wouldn't be possible to cache TB
> but is caching really helping the speed?

It is get_BMC and not get_cost.

We _could_ merge get_BMC, get_ECOT and get_TB into one function (which
would be similar to get_COP) but I don't see the reason for it. Speed
isn't a good one IMHO. My ordered list of goal for development is
still: correctness, maintainability, speed. Warmap had great speed but
low maintainability. You change this with PF but you can't get both
easily. Inlining is a good way to get speed without affecting

> get_cost callback has more variables than is really necessary.  One
> can of course use MAPSTEP to generate those on site, but I am not
> convinced it's faster than passing them.

I guess that passing is faster. But nobody stops such a called
function from doing a check via an assert that the given map position
is really the one expected.

> Anyway, I hope you find new interface ok.

We can remove 
+  struct player *owner;
+  bool zoc_used;
+  bool omniscience;

and also the tile-known management.


 email: rf13@xxxxxxxxxxxxxxxxx
 "Make it idiot-proof and someone will make a better idiot."

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