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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Apr 15, 2002 at 08:54:55PM +0100, Gregory Berkolaiko wrote:
> 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.

You can just use the space of an int for two shorts. So you are
independent of MAX_X.

> > 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.

Attached a version which have the requested changes. You would want to
wrap an int in the void *.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Reality? That's where the pizza delivery guy comes from!"

path_finding7.h
Description: Text document