[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Apr 08, 2003 at 11:03:59PM -0500, Jason Dorje Short wrote:
> Raimar Falke wrote:
> >On Mon, Apr 07, 2003 at 01:06:17PM -0500, Jason Dorje Short wrote:
> >
> >>Raimar Falke wrote:
> >>
> >>>On Sun, Apr 06, 2003 at 04:08:42PM -0500, Jason Dorje Short wrote:
> >>>
> >>>>Raimar Falke wrote:
> >>
> >>>>The directions *are* rotated, yes.  Note that the DIR_D[XY] arrays 
> >>>>would have to be changed for native coordinates, and they would be 
> >>>>different between iso and non-iso maps.  The conclusion is that native 
> >>>>coordinates are not good for local operations like moving in a single 
> >>>>direction, and these are best done in map coordinates.
> >>>
> >>>
> >>>So what do you think about the following proposal: 
> >>>- we leave the storage of the map tiles unchanged
> >>>- we add an iso bit to the map struct (save and transfer it)
> >>>- we change DIRSTEP, MAPSTEP, is_cardinal (trivial)
> >>>- we doesn't need to change is_normal_map_pos, is_real_map_pos,
> >>>whole_map_iterate and is_border_map_pos
> >>>- we change normalize_map_pos (seems trivial)
> >>>- we change the mapview to do the rotation (non-trivial)
> >>>
> >>>How does this differ from the use of iso-maps you have in mind? What
> >>>did I miss? For the mapview changes the notation of native coordinates
> >>>help a lot but these is limited to only one set of files
> >>>(mapview_common).
> >>
> >>I don't quite understand your suggestion.  Are you saying all operations 
> >>be done in native coordinates, and "map" coordinates be dropped?  The 
> >>problem with this is most local operations become much more difficult, 
> >>since the local tile geometry is not preserved.  For instance 
> >>adjc_dir_iterate (via DIR_D[XY]), square_iterate, map_to_city_map, 
> >>map_distance, etc.  This will require many changes to the code, and will 
> >>be error-prone.
> >
> >
> >My suggestion is to leave a lot of the code untouched (see the list
> >above). A layer is needed to express the iso-map. But only a thin
> >layer. I _think_ that this layer will only consists of the dir
> >transformation. So we would have a "normal map" direction and a
> >(map)view direction and the relation is either identity (non-iso maps)
> >or dir_cw (iso-maps). This layer is thin and a lot thinner than the
> >layer you describe. I'm not sure that my layer is complete. So I'm
> >still asking for all the effects of the iso-map. But if it is only
> >rotating is should be not much more.
> 
> Err, you didn't answer my question.  

> But I think you have not thought through things fully.

That is quite possible. I'm still trying to understand.

> How would you implement:
> 
>   - square_map_iterate

What is the semantic for this for the iso-map case?

 a b c d e
f g h i j k
 l m n o p 
q r s t u v 
 w x y z 1

Will square_map_iterate(n,1) return [h, i, s, t]? Or [h, i, s, t, c,
m, o y]?

>   - map_distance/real_map_distance/sq_map_distance
>     (presumably map_distance_vector is easy)

Same here. Is map_distance(a, c) == map_distance(a, m) == 2?

>   - canvas_to_map_pos/map_to_canvas_pos (ignoring wrapping issues)
>   - show_city_descriptions/update_map_canvas
> 
> it's not just a question of how many places need to be touched, but of 
> how difficult/ugly/unmaintainable the new code will be.

The last two are map view related. I stated that the changes to map
view are non-trivial. But these changes are isolated to map-view.

Also I think that in my idea I want to make your native coordinates
the "normal" "map" coordinates.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner