Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: [RFC] Move cost map interface
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 15 Apr 2002 21:37:04 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

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

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.

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. 

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.

        Raimar


-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Only one human captain has ever survived battle with the Minbari
  fleet. He is behind me. You are in front of me. If you value your 
  lives, be somewhere else."
    -- Ambassador Delenn, "Severed Dreams," Babylon 5


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