Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2003:
[Freeciv-Dev] (PR#6170) Alternative city square utilizations
Home

[Freeciv-Dev] (PR#6170) Alternative city square utilizations

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdwheeler42@xxxxxxxxx
Subject: [Freeciv-Dev] (PR#6170) Alternative city square utilizations
From: "Remi Bonnet" <remi.bonnet@xxxxxxxxxxx>
Date: Thu, 9 Oct 2003 09:29:19 -0700
Reply-to: rt@xxxxxxxxxxxxxx

[rwetmore@xxxxxxxxxxxx - Wed Sep 17 17:01:30 2003]:

> 
> One of the simplest ways to handle arbitrary city shapes is to update the
> citymap macros to accept an arbitrary list of indexed city tile offsets,
> or a masking function on a given list. This will cover 90% of accesses.
> This will also move to a system that Renier has been looking for for a
> long time in which functional distance relationships are *not* the basis
> for adjacency rules.
> 

I fear this is not so simple. Statically alloced arrays are spread in
all the code (especially cm.c and city.c)

> But as Jason points out, there are a number of places where an exact
> distance computation (for GUI layout), or validity check like
> is_real_citymap_pos() are done, that may be expensive to generalize, i.e.
> waking the linear list should be considered a non-starter.
> 
> The first step should be to go over the code and identify all such changes
> then writeup an RFC that suggests how the common and less common elements
> might be coded.
>

Here are quick thoughts
 * For the macros, the best way to avoid an enormous slowdown is to
generate indices at ruleset load, after we know what is the max radius
that can be reached.
 * For the cm, a new field in the cache3 structure: currently_alloced.
Each time the cm is called, it verifies that the cache is enough big for
the city. In the other case, a realloc is done (huge CPU eating)

> One can also add the arguments in favour of doing this, or against, and
> then send it on to a review board for priority and validity assessment.

For:
 * a nice feature that makes the game more realistic and increase make
the largepow strategy slightly more viable.
 * ruleset customization: good

Against:
 * more CPU usage OR more memory for caching.
 * a lot of time is needed to find all the places where there are static
allocation, or use of CITY_MAP_SIZE, CITY_TILES...

As far as i'm concerned, this feature is a good one.

> Cheers,
> RossW
> =====

Attached is a *useless* patch that replace the 5 in city.h by
CITY_MAP_SIZE. However, i think that such an use of hard-coded number is
bad. 

Remi

--- ../freeciv/common/city.h    2003-10-02 15:11:10.000000000 +0200
+++ ./common/city.h     2003-10-09 18:28:00.000000000 +0200
@@ -187,14 +187,14 @@
 
   /* Used for caching when settlers evalueate which tile to improve,
      and when we place workers. */
-  signed short int detox[5][5];
-  signed short int derad[5][5];
-  signed short int mine[5][5];
-  signed short int irrigate[5][5];
-  signed short int road[5][5];
-  signed short int railroad[5][5];
-  signed short int transform[5][5];
-  signed short int tile_value[5][5];
+  signed short int detox[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int derad[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int mine[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int irrigate[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int road[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int railroad[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int transform[CITY_MAP_SIZE][CITY_MAP_SIZE];
+  signed short int tile_value[CITY_MAP_SIZE][CITY_MAP_SIZE];
 
   /* so we can contemplate with warmap fresh and decide later */
   int settler_want, founder_want; /* for builder (F_SETTLERS) and founder 
(F_CITIES) */

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