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 development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 Apr 2002 08:43:16 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Apr 09, 2002 at 08:55:30PM +0100, Gregory Berkolaiko wrote:
> Attached is my go at the unified move cost map generation.
> Comments are in the code.
> 
> G.

> /* Copyright and ifdefs come here */
> 
> 
> 
> /********************* Individual Cost *******************/
> /* costs can be anything, but usually cost1 is the basic move cost and
>  * cost2 is a penalty due to exposure to various dangers
>  * can easily increase number of additional costs, if necessary */
> struct movecost {
>   int cost1;
>   int cost2;
> }
> 
> 
> 
> /********* Individual Position / Location / Tile ********/
> 
> struct location {
>   int x, y;                    /* coordinates */
>   struct movecost travelcost;  /* cost to get here */
>   char from;                   /* where we came from 
>                                 * (bitmap holding directions) */
>   enum queue_status status;    /* holds various queue related info */
> }
> 
> /* Access functions */
> int location_get_x(struct location *);
> int location_get_y(struct location *);
> /* Might also need this 
>  * (not sure about usage of const, 
>  * here I want to prevent changing the pointer's contents */
> const struct movecost *location_get_cost(struct location *);
> 
> 
> 
> /******************** HRM The Cost Map ******************/

HRM stands for?

> /* Type of the map */
> enum maptype {
>   UNITLAND, UNITSEA, CITYLAND, CITYSEA, CUSTOM 
> }
> 
> /* Generic move cost function 
>  * Can pass some more info using void * 
>  * (it will probably need pplayer, moverate, what else?)

>  * Will probably return pointer to the static internal 
>  * struct movecost */

Are the locations adjacent?

> typedef struct movecost * (COSTFN)(struct location *from,
>                                    struct location *to, 
>                                    void *);
> 
> 
> struct costmap {
>   struct location[XMAX][YMAX]; /* the map itself */
>   struct pqueue *queue;        /* priority queue for holding 
>                                 * accessible (but not yet processed) 
>                                 * locations */
>   enum maptype {
>     UNITLAND, UNITSEA,
>     CITYLAND, CITYSEA, 
>     CUSTOM 
>   } type;                      /* type of the map */
>   void *object;                /* the city / unit for which the map
>                                 * is generated; the type should be 
>                                 * clear from the maptype */
>   int orig_x, orig_y;          /* the origin of the map */
>   COSTFN *cost_function;       /* supplied only if type == CUSTOM */
> }
> 
> /* NOTES:
>  * 1. Instead of "object" we can have two pointers to unit and city, 
>  *    with only one being non-NULL at any time
>  * 2. Unit is used for info such as moverate and igter, NOT to get
>  *    orig_[xy]
>  * 3. More info can be recorded in this struct, like moverate... 
>  *    IGTER can have their own maptype 
>  * 4. Separation between "traditional" cost functions and "custom" 
>  *    cost functions is done for performance.  At first wqe can make 
>  *    all of them CUSTOM, and then try inlining them */
> 
> 
> /* The comparison function for the priority queue.
>  * We might have to put it into the costmap structure, in case some
>  * very exotic costs emerge */
> int priority_cmp_function(struct location *from, struct location *to);
> 
> 
> /* Cost map generating functions */
> /* Creation / init */
> struct costmap *cm_create(int x, int y, struct maptype, 
>                            void *object, COSTFN *);
> /* Iterators -- only useful if you think you will terminate early */
> struct location *cm_get_next_location(struct costmap *);
> void cm_process_next_location(struct costmap *);
> /* Generating the full map -- includes creation and generation */
> struct costmap *cm_get_in_full(int x, int y, struct maptype, 
>                                void *object, COSTFN *);
> /* Cleanup */
> void cm_destroy(struct costmap *);
> 
> /* NOTES:
>  * 1. cm_process_next_location can probably be incorporated into 
>  * the beginning of cm_get_next_location.  Thinking... */
> 
> 
> /* Access functions */
> int cm_get_cost1(struct costmap *, int x, int y);
> int cm_get_cost2(struct costmap *, int x, int y);
> /* I don't think anything like this would be needed... */
> int cm_get_total_cost(struct costmap *, int x, int y);

In summary you put the current gotohand.[ch] in an interface.

Things that I dislike:
 - the maptype. This is IMHO an error in the current goto(hand).[ch]
 files.
 - you expose too many details. Remove all the stuff which is implemention 
specific.
 - you missed the ability to calculate the turns to reach a
 target. This is required for my further agents and has to be
 included.
 - serveral smaller problems: char for example can only hold the
 bitmask up to 8 directions, no enum goto_move_restriction, ...

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure 


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