[Freeciv-Dev] Re: (PR#6721) A Quincuncial topology

["Marcelo Burda" <mburda@xxxxxxxxx>]

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


> Background:
> 
> is_reversed is a boolean value that applies to a particular position. 
is_reversed is a descriptor of reverse procesus at x1,y1, i need it to
reverse tiles, actulay a boolean is good.
In more generalized topologies we can use a enumerate 0(==FALSE) for no
reversion, 1 flip X, 2 flip Y, 3 full reversed(==180° rotation== flip x
and flip y), 4 90° rotation , 5 270 rotation. (4 and 5 are limited to
exact square maps, probably never used).
reverse is interesting because is autoinverse, then a boolean is good
for it.
> If it is true, then the particular invocation of the position that we're
> dealing with is reversed as compared to the normalized version of that
> position.  So when we normalize the position we determine whether or not
> it is reversed.
> 
> It probably makes more sense with an example.  There is an
> adjc_dir_iterate_isreversed macro.  It's just like adjc_dir_iterate
> except it also gives an is_reversed flag for each position returned
> (determined via a specialized normalize operation).  So the code in path
> finding to iterate around a particular position goes like:
> 
>   adjc_dir_iterate_isreversed(x0, y0, x1, y1, dir, is_reversed) {
>     node1 = get_node(x1, y1);
>     /* ... */
>     node1->path_to_here = normalize_dir(dir, is_reversed);
>   } adjc_dir_iterate_isreversed_end;
> 
> normalize_dir, of course, just reverses the direction if the is_reversed
> flag is set.
> 
> This is a prime example of (current) code that won't work without
> changes when the map is not well-oriented, so some type of change is
> needed here.  But I think the is_reversed method is not a good one.
> 
> Mathematically, I think it's not a clean solution.  In the above case,
> the is_reversed flag applies to the pre-normalized (x1,y1) position - a
> value that doesn't even exist.  We're passing around a flag that doesn't
> have meaning outside of its direct context.  The result is that the code
> is not very intuitive.  It also prevents any future topology from having
> orientation other than standard or reversed.
> 
> In general, I think we have to do normalization of directions along with
> their original position.  For instance instead of keeping around the
> is_reversed value we should take the pre-normalized position and call
> 
>   dir = normalize_dir(x1, y1, dir);
> 
> on the direction, or better yet
> 
>   normalize_vector(&x1, &y1, &dir);
> 
> Now in the above case I think all the work should be done by the macro.
>  So the code should read
> 
> 
>   adjc_dir_iterate_full(0, y0, x1, y1, dir0, dir1) {
>     node1 = get_node(x1, y1);
>     /* ... */
>     node1->path_to_here = dir1;
>   } adjc_dir_iterate_full_end;
> 
You are right it is more clear; i begin in this model then i split this,
 some time i need a reverse descriptor for reverse the tiles in client
or for reverse the keyboard control but ia not need it. we can easy
joint its:

#define adjc_dir_iterate_full(x0, y0, x1, y1, dir0, dir1)              \
adjc_dir_iterate_isreversed(x0, y0, x1, y1, dir0, is_reversed)         \
int dir1=NORMALIZE_DIR(dir0, is_reversed);

to use every where, when reverse descriptor are not needed 
 
> where dir1 is the version of dir0, with respect to (x1, y1).  (Better,
> we could return the direction needed to get from (x1,y1) back to
> (x0,y0).  Thus (x0,y0,dir0) is the inverse vector of (x1,y1,dir1).  The
> important point is that dir0 is relative to (x0,y0) while dir1 is
> relative to (x1,y1).  And dir1 has a concrete meaning that programmers
> can wrap their minds around.
yes
> In general, rather than tracking an is_reversed value we should track
> the orientation of the tile in terms of a direction (a direction8).  And
> instead of tracking directions and orientations separately, we should
> track _vectors_ wherever possible.
yes, if possible
> jason
>