Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] Re: (PR#8817) generate city map indices
Home

[Freeciv-Dev] Re: (PR#8817) generate city map indices

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#8817) generate city map indices
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>
Date: Sun, 23 May 2004 10:55:40 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8817 >

A somewhat useless comment.

You can also sort the indices of the same distance, to guarantee that the
iteration "on the circle" is done, say, clockwise from 12 o'clock

if (dx1 >= 0) {
  if (dx2 < 0) return -1;
  if (dy2 >= dy1) return -1;
  return 1;
}

etc

On Sun, 23 May 2004, Jason Short wrote:

>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8817 >
>
> This patch is a rework of Remi's patch in PR#7350 to generate the city
> map indices.
>
> I've changed it in several ways:
>
> - Rathar than a linked-list solution with insertion sort I used a purely
> array solution with qsort.  This requires much less code (and is no
> doubt faster but who cares).
>
> - The radius is _not_ passed to the generate function.  Rather the
> generate function should already know the radius.  If the radius is
> loaded from the ruleset, for instance, it will be stored in some global
> variable.
>
> - Rather than calling the function when the ruleset is loaded I call it
> when the game starts.  This is a bit questionable but I'm not sure where
> else it should go.
>
> - I use fc_realloc to avoid memory leaks when generate_indices is called
> multiple times (when the server plays multiple games, or the client
> reconnects).
>
> My goal here is a little broader than Remi's.  His original patch only
> considered that the indices might be changed based on the ruleset.
> However I'm thinking about hex-tiled maps too, where the indices are
> changed based on the topology.
>
> As a side note I would like to use a similar solution (reusing the
> iter_index struct) for iterate_outwards in map.h.  For iterate_outwards
> (and in Remi's city-radius patch) it is actually useful to have the
> distance stored in the array so that you can tell when it's time to stop
> the iteration.  However for the current code the "dist" element is
> unused except in the generation of the array.
>
> As another side note it is easy to make city_map_iterate a wrapper for
> city_map_iterate_outwards.  I believe this is what Ross has suggested.
> In fact it might be simpler to remove city_map_iterate_outwards and just
> make all citymap iteration follow the outwards ordering.
>
> jason
>
>




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