[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 06:15:29PM +0100, Gregory Berkolaiko wrote:
> > On Mon, 15 Apr 2002, Raimar Falke wrote:
> > 
> > > > > It is just not part of the interface. And pf_map will get bigger. You
> > > > > need for example a way to cache the per tile extra cost, the per tile
> > > > > zoc value and so on. And if pf_position is public you can't store it
> > > > > in pf_position.
> > > > 
> > > > These are the things you can add later.  We should at least sketch the 
> > > > implementation.
> > > 
> > > We have a sketch in our heads and in gotohand and goto_agent. But this
> > > isn't important.
> > 
> > We are now tying to design something which is fast and easy-to-use.
> > And the need to make it fast will inevitably show on the face 
> > (inter-face).  
> 
> > This is why I wanted to hide pf_position: we need to decide what is
> > the best implementation from the performace point of view.  So
> > please repeat you reasons why pf_position should be made public.
> 
> IMHO it is better to provide the data in a struct than to provide 2-3
> functions which provide the data. From the performance point of view
> and also for clarity
> 
> > I actually think we should use Ross's warmap.c as the prototype.
> 
> If we have an interface everybody may provide an implementation. Which
> one goes is will depend on performance, code readability and
> correctness.

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

Best,
G.