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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Raimar Falke wrote:
> 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
Note, these are iso-natural, not iso-native coordinates.  The iso-native 
variant would be
  abcde
  fghijk
  lmnop
  qrstuv
  wxyz1

(It's not a perfect rectangle because the dimensions are wrong.  If you 
added another column to the original map, it would be correct.  When you 
deal in native coordinates, this just "works out" - you say you want a 
6x5 map and you get the correct one.)
> 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?
Both of these operations are local; they don't care about the topology. 
 Think about it from a gameplay perspective - a unit's area of vision 
doesn't change just because the underlying map is different.
So, the definition is unchanged from the current form - which makes it 
difficult or impossible to calculate using native iso coordinates.
square_map_iterate(n, 1) should give

    mhc
    sni
    yto

and map_distance(a,c) = 4; map_distance(a,m) = 2 (the 
real_map_distance() for both would be 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.
No, these are basically the same problem as the above. 
canvas_to_map_pos/map_to_canvas_pos is comparable to map_distance (you 
have to add/subtract the dx,dy onto map_view_x0/map_view_y0, which can 
only be done in map coordinates), and 
show_city_descriptions/update_map_canvas is comparable to square_iterate 
(iteration over a rectangle or iso-rectangle in map coordinates). 
Again, both are difficult or impossible to do in native coordinates.
> Also I think that in my idea I want to make your native coordinates
> the "normal" "map" coordinates.
That's what I thought.

The thing to remember is that there is not, and can not be (for the 
reasons given above), a single set of coordinates.  So we can use 
whatever coordinates are handy for each operation.  It is easiest 
(requires the fewest changes by far) to keep most functions (like 
map_get_tile) dealing in map coordinates.  We could convert all the code 
to deal in native coordinates, and only switch to map coordinates when 
we need them - but this will take a lot of effort.  Since native 
coordinates are less intuitive for more people, it's probably not a good 
idea anyway.
For the record, square_iterate could then be implemented as

  #define square_iterate(center_nat_x, center_nat_y, radius, nat_x, nat_y)
  {
    int dx_itr, dy_itr, center_map_x, center_map_y;
    native_to_map_pos(&center_map_x, &center_map_y,
                      center_nat_x, center_nat_y);
    for (dy_itr = -radius; dy_itr <= radius; dy_itr++) {
      for (dx_itr = -radius; dx_itr <= radius; dx_itr++) {
        int map_x = dx_itr + center_map_x;
        int map_y = dy_itr + center_map_y;
        map_to_native_pos(&nat_x, &nat_y, map_x, map_y);
        if (normalize_map_pos(&nat_x, &nat_y)) {

which isn't too bad.  But square_dxy_iterate would have to give a map 
vector as its (dx,dy) pair.  And lots of other places (not sure how 
many) would need similar changes.
jason