Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2002:
[Freeciv-Dev] Re: [RFC] Path finding implementation.
Home

[Freeciv-Dev] Re: [RFC] Path finding implementation.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Path finding implementation.
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Sat, 29 Jun 2002 21:09:26 +0200

On Sat, Jun 29, 2002 at 07:31:04PM +0100, Gregory Berkolaiko wrote:
> Mmm...
> 
> If by any chance in due time you agree that one of the models is better 
> that the others, please let me know in Common.  In the mean time please 
> fill free to talk in sanskrit or whatever you are using...
> 
> I did however understand the parts of the code written in C.  And the big 
> difference b/w Ross' test code and path_finding_*.c is that access to 
> lattice is not linear, like
> 
>      for(i = 0; i < 80; i++) {
>        for(j = 0; j < 50; j++) {
>          tiles[j + i * 50] = i + j;
>        }
>      }
> 
> But it's not exactly random either.  Most of (x,y) to lattice_offset xy 
> conversions come from 
>       adjc_iterate(x, y, x1, y1) {
>         xy1 = x1 * 50 + y1;
>         /* .... */
>       }
> 
> Thus if we had an iterator working directy with xy, 
>       adjc_xy_iterate(xy, xy1) {
>         /* ... */
>       }
> this would make indexed approach both the most convinient and the fastest.

I don't think that you can improve the access much beyond two memory
accesses and one lea (which you get with 2D array).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  What's nice about GUI is that you see what you manipulate.
  What's bad about GUI is that you can only manipulate what you see.


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