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

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 19 Feb 2003 21:11:30 +0000 (GMT)

On Wed, 19 Feb 2003, Raimar Falke wrote:

> On Wed, Feb 19, 2003 at 08:20:11PM +0000, Gregory Berkolaiko wrote:
> > On Wed, 19 Feb 2003, Raimar Falke wrote:
> > > > > 
> > > > > It is get_BMC and not get_cost.
> > > > 
> > > > I never liked BMC or for that matter any of the abbreviations.  They 
> > > > are 
> > > > not user-friendly and so reduce maintainability.
> > > 
> > > "cost" is just too general.
> > 
> > move_cost ?
> 
> Same. You can use any name you like in the implementation but the
> interface should stay clean.

Hmmm, I wouldn't call an abbreviation like BMC "clean".
And you are being obstinate for obstinancy's sake as "move_cost" is not 
too general.  It can mean only one thing: cost of move.  Term "basic" 
doesn't help to make it more special.

But I don't really care...

> > > +    node->behavior =
> > > +        params->get_TB(x, y, node->node_known_type, params->get_TB_data);
> > > 
> > > +    node->extra_tile =
> > > +        params->get_ECOT(x, y, node->node_known_type,
> > > +                         params->get_ECOT_data);
> > > 
> > > Both can be done in the callbacks.
> > 
> > You mean both requests for the known type?  I agree.
> 
> The known parameter is removed from the signatures and the called
> functions query the known state by itself if required.

Yes.

> > ZoC cannot be done in get_TB, because move_ZoC_allowed is a two-tile 
> > function and TB is one-tile function
> 
> Correct. Than we could add ZoC handling to get_BMC.

Ok.

> > > About the known-management: if we remove it from the core code:
> > >  - it will reduce the number of parameters
> > >  - it will reduce the size of the cell/node
> > 
> > true.  Less memory -- faster.
> > 
> > >  - it will increase run-time because of extra function calls to
> > >  map_get_known by the user functions.
> 
> > mind you, caching can still be done through void *data parameter.
> > We can pass pointer to caching map.
> 
> Can you explain more?

we make
struct cached_values {
        int is_initialized;
        int known;
        int zoc_number;
        int behavior;
}

then 
struct last_arg {
        struct player *owner;
        struct cached_values *vals;
} cache;

and then do (at fill_parameter time)

cache.vals = fc_calloc(...)

get_BMC_data = &cache;
get_ECOT_data = &cache;

then inside, say, get_BMC, we do 

if (!data->vals[index].is_init) {
        data->vals[index].known = is_known_tile(x, y, owner);
        // .....
}

if (data->vals[index].known == TILE_UNKNOW) {
        return 0;
}

Almost the same as we have now, just done in callbacks themselves.

G.



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