[Freeciv-Dev] Re: [RFC] Move cost map interface

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Mon, 15 Apr 2002, Raimar Falke wrote:

> On Mon, Apr 15, 2002 at 08:20:59PM +0100, Gregory Berkolaiko wrote:
> > 
> > 
> > Okay, let me say it out loud: I don't really care what path struct will 
> > look like and what information it will provide.  What I care about is 
> > pf_get_next_position and the value it returns.  It should return some sort 
> > of pointer into some sort of internal cost(war)map element using which 
> > one can extract the coordinates of the next location and the relevant 
> > costs.
> > 
> > If the implementation will be performace-orientated, this structure will 
> > not look like pf_position as you've defined it.  Therefore the second 
> > agrument to pf_get_next_position will not be struct pf_position *, but
> > struct pf_location * or even an int *.
> > 
> > Thus we have a separation: pf_position is a member of path and pf_location 
> > (or whatever it will be called) is the map element (containing minimum 
> > info) to be used by the map-generation internals.  
> > 
> > The functions I'm interested in will look like this:
> >     pf_location pf_get_next_position(pf_map_t map);
> > and
> >     void pf_construct_path(pf_map_t map, const pf_location,
> >                                struct pf_path *path);
> > with pf_location being some type which will emerge during implementation 
> > development.  BTW, I'm not terribly interested in pf_construct_path 
> > either, but I thought we should have it for some future uses might emerge.
> > 
> > If we agree on that, then I have no other qualms about the path_finding6.h
> > (maybe some more minor corrections will emerge on contents of 
> > pf_parameter but I don't see anything now).  Probably this is what you 
> > originally had in mind...
> 
> Then please tell me how do you extract the x and y from the int *? You
> have to extract these to be able to test the exit condition. Either
> you will construct the whole path (which you don't want to do) or you
> get x and y from pf_get_next_position.

actually I meant just int, which is the offset into the vector of all 
locations (see Ross' implementation), that is 
x*MAX_X + y.  Extracting is done in a macro, and is fast if MAX_X is a 
power of 2.

> I have also thought about a seperate struct as return value of
> pf_get_next_position. But pf_position can handle it quite well. So we
> use only parts of the struct. 

Why waste memory?

> But I have no great problems if you want another struct. Should this
> just be a stripped down version of pf_position (x,y, moves_left)? Or
> something which is determined by the implementation? But remember x
> and y have to be accessible. So you can't really make the struct
> private.

We can always write an access function.  Have a look at Ross' 
implementation that I sent you.  Very illuminating.

G.