Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2004:
[Freeciv-Dev] Re: (PR#8959) remove CAR_DIR_D[XY]
Home

[Freeciv-Dev] Re: (PR#8959) remove CAR_DIR_D[XY]

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8959) remove CAR_DIR_D[XY]
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Jun 2004 05:30:37 -0700
Reply-to: rt@xxxxxxxxxxx

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

Gregory Berkolaiko wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8959 >
> 
> On Mon, 21 Jun 2004, Jason Short wrote:
> 
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8959 >
>>
>>>If the ordering of the directions is changed to rotational, the test for
>>>cardinal-ness is just a test for even-ness (or odd-ness).
>>
>>Except on a hex map.
> 
> On a fake hex map you mean.  Because on a real one every valid direction
> is cardinal (edge-joined with the center tile).

I'm talking about a real hex map.  Yes, every valid direction is 
cardinal (but note there are some invalid directions).  However you 
can't just do a "dir += 2" or "if (dir % 2 == 0)" to skip over 
non-cardinal directions because it will fail on a hex map.

>>We have a similar problem for adjc_dir_iterate in that in hex maps not
>>all directions are "valid".  So either we need a call to is_valid_dir
>>here or we need something else clever.  adjc_dir_iterate actually is
>>used a lot (unlike cart_iterate which is almost never used) so there
>>actually is a speed issue here.  However the alternatives have drawbacks
>>as well:
> 
> I am not quite sure whether the below are disjoint alternatives or
> combinable parts.

To some degree, both.

>  So here is a proposal based on some of them:
> 
> Part (a)
> 
>>Make new arrays VALID_DIRS[] and CARINDAL_DIRS[].  These arrays
>>contain the list of valid (for adjc_dir_iterate) and cardinal (for
>>cart_iterate) directions.  Of course these arrays must be initialized,
>>and that means extra code (in init_topology).
> 
> 
> Part (b)
> Make two variables NUM_VALID_DIRS and NUM_CARD_DIRS which give sizes of
> the arrays from part (a).

Another alternative is to terminate the array with -1, but that seems 
less pretty.

Also, rather than making these into all-new global variables I'd like to 
put them into the map variable, e.g., as map.valid_dirs[] and 
map.num_valid_dirs.  The same should probably be done eventually with 
DIR_DX/DIR_DY.  (Note that all of these are part of the topology not 
really part of the map - but the topology is included in the map for now.)

> Part (c)
> Make a macro
>   dir_array_iterate(...., dir_array, num_dirs)
> 
> Part (d)
>    #define adjc_dir_iterate(...) \
>      dir_array_iterate(..., VALID_DIRS, NUM_VALID_DIRS)
> 
>    #define cart_iterate(...) \
>      dir_array_iterate(..., CARD_DIRS, NUM_CARD_DIRS)

Actually this is exactly what I had in mind when proposing the arrays. 
It's a good sign that you have the same idea.

> This, I feel, will have the best features of Ross' model and be more
> extensible because the subset of dirs over which you want to iterate next
> doesn't have to form an arithmetic progression in the total set of all
> directions.

OK.  This still has the drawback that the dir arrays must be created in 
init_topology:

   map.num_valid_dirs = map.num_cardinal_dirs = 0;
   for (dir = 0; dir < 8; dir++) {
     if (is_valid_dir(dir)) {
       map.valid_dirs[map.num_valid_dirs++] = dir;
     }
     if (is_cardinal_dir(dir)) {
       map.cardinal_dirs[map.num_cardinal_dirs++] = dir;
     }
   }

which isn't really that much code but adds an extra dependency among 
different parts of the code.

Note that this will be trivially slower than what we have now, because 
an extra array lookup (into the ***_DIRS array) is needed.  It is 
however better than a skip-over-the-bad-dirs method, since that either 
requires what I proposed: a check on each dir (which is slow) or what 
Ross proposed: a dir increment other than 1 (which isn't extensible).

> P.S. I still remain very sceptical about new topologies such as hex or
> quincical.  I think there are more worthy issues to be dealt with.

Players on the apolyton forum seem very excited about the possibility of 
hex tiles; one of them gave a good explanation of why it may give better 
gameplay.  Quincuncial is mostly of mathematical interest and you are 
right to be skeptical (but mathematical interest is not of no account: 
freeciv may not be a teaching tool but making a fun game educational is 
an excellent means of teaching).

http://apolyton.net/forums/showthread.php?s=&threadid=73376

jason




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