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: "Per I. Mathisen" <per@xxxxxxxxxxx>, Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: (PR#2370) Path finding
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Tue, 18 Feb 2003 16:10:53 +0000 (GMT)

On Tue, 18 Feb 2003, Raimar Falke wrote:

> On Tue, Feb 18, 2003 at 03:44:16PM +0000, Gregory Berkolaiko wrote:
> > Just for the reference,
> > <Raimar wrote>
> > You get full control over the cost (get_BMC, get_ECOT) and the
> > termination condition (get_TB). You may want additionally to do the
> > moves_left and turn calculation by yourself. If the *_data stuff and
> > the comments are removed:
> > 
> > struct pf_parameter {
> >   int start_x, start_y;
> >   void (*update_turn_and_moves_left) (int *, int *, int, int);
> >   enum tile_behavior (*get_TB) (int, int, void *);
> >   int (*get_ECOT) (int, int, void *);
> >   bool(*is_position_dangerous) (int, int, void *);
> >   int (*get_COP) (int, int, int, int, void *);
> > };
> > 
> > This is quite minimal. Do you want this?
> > <end quote>
> > 
> > Yes, I agreed to it and I still do.  You forgot to add get_BMC call-back, 
> > but otherwise almost everything you need is there.
> 
> Looks so.
> 
> > The hard problem is to decide what info to pass to get_BMC, though.
> 
> The source position of the step, the direction and the data_pointer.
> 
> > > This is btw also a flaw in the recent pf*.diff: the use of callbacks
> > > for the BMC. _IIRC_ you said that this is an error and you want to fix
> > > it.
> > 
> > I don't think I said it's an error.  Probably I said it could possibly be 
> > made faster by turning it into a switch and then new callbacks would be 
> > equivalent of adding a new switch to the statement.  I am not 100% sure it 
> > would be much faster though, but one can try...
> 
> Be aware that the interface from above is inherently slower.

The interface from above matches _very_well_ with the current
implementation.  It's just that the current implementation was screwed to
fit into Procrustrian bed of your interface (I admit I agreed to it, after
much torture ;).

G.



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