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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Apr 10, 2003 at 02:37:15PM -0500, Jason Dorje Short wrote:
> Raimar Falke wrote:
> >On Wed, Apr 09, 2003 at 06:30:12AM -0500, Jason Dorje Short wrote:
> >
> >>>That is quite possible. I'm still trying to understand.
> >
> >
> >Another try. See the two attached pictures. So there is a compact form
> >and a rotated form. Both are identical for non-iso maps. In addition
> >there is the view form which it hard to draw so I use ascii here.
> 
> I think you're just getting more confused - and certainly you are 
> confusing me.

> Try using the same nomenclature that we are using.  There are three 
> forms - the map form, the natural form, and the native form. 
> Additionally there is the iso-view form and the non-iso view form (which 
> may correspond to one of the above forms, but only by lucky 
> coincidence).  You may want to read back over the original patch.

It may possible that there is a different thinking and you can't
convert them easily.

> >View form (iso tileset):
> >
> >    a b c d e f g h i
> >1   # # # # # # # # #       Since it isn't clear I specify that the
> >2    # # # # # # # # #      tile right below b1 is called b2 and not a2.
> >3   # # # # # # # # #
> >4    # # # # # # # # #
> >5   # # # # # # # # #
> 
> This is the iso-view form.  It also happens to be the natural form for 
> an iso map.
> 
> >View form (non-iso tileset):
> >  Similar to grid_rot.png.
> >
> >The view form is irrelevant for the semantics of the functions since
> >it depends on the view (iso tileset or non-iso one)?! It looks like
> >this is untrue: you specify the semantics of the function based on the
> >iso tileset view form since otherwise the semantic of
> >square_map_iterate doesn't changes (it is the same for compact and
> >rotated form). Yes/no?
> 
> I don't know what this means.

Think about how you would like to define the neighborhood of a
position. You need this for adjc_iterate, vision_range and some other
basic uses. In which form will this definition show a natural (this
has nothing to do with your coordinates of the same name) shape
(rhombus, rectangle)? It is clear that it can't be a natural shape in
all forms (if it is a natural shape in iso-view of an iso-map it can't
be in the non-iso-view of an iso-map AFAIK). It is also clear that it
may be possible to have multiple square_*_iterate functions but only
one of them is used for the "real stuff" like vision range.

> >So square_map_iterate(d3) is
> >
> >    a b c d e f g h i
> >1   # # # o # # # # #
> >2    # # o o # # # # #
> >3   # # o + o # # # #
> >4    # # o o # # # # #
> >5   # # # o # # # # #
> 
> Yes.  But it is easier to think of it in map coordinates:
>    21 a
>   43 # b
>   5 ### c
>    ##### d
>     ##ooo e
>      #ooo# f
>       ooo## g
>        ##### i
>         #####
>          ####
>           ##
> 
> which means that, in map coordinates, the semantics are unchanged from 
> the original.

You know that these are not the same?! Also the form you draw here is
an iso-view of a non-iso map. Iso-maps are rotated in the other
direction.

> >which is in the compact form
> >
> >    a b c d e f g h i
> >1   # # # o # # # # #
> >2   # # o o # # # # #
> >3   # # o + o # # # #
> >4   # # o o # # # # #
> >5   # # # o # # # # #
> >
> >That is [c2, c3, c4, d1, d2, d4, d5, e3]. Yes/no?
> 
> In native coordinates, yes.  That's why we don't use native coordinates 
> for local operations :-).
> 
> >Just for completeness: if we define this semantics of the operations
> >at the compact or the rotated for the answer would be:
> >
> >square_map_iterate(d3)
> >    a b c d e f g h i
> >1   # # # # # # # # #
> >2   # # o o o # # # #
> >3   # # o + o # # # #
> >4   # # o o o # # # #
> >5   # # # # # # # # #
> >
> >That is [c2, c3, c4, d2, d4, e2, e3, e4].
> 
> If you define square_nat_iterate, i.e., define the semantics in terms of 
> native coordinates this is what you would get.  Note that this block 
> would be quite useless, it would give you a shape like
> 
>      o
>     ooo         o o o
>    o+o    <=>  o + o
>    oo           o o o
> 
> which would have a different shape than square_nat_iterate(d2):
> 
>                  oo
>   o o o         o+o
>    o + o  <=>  ooo
>   o o o         o
> 
> >I'm hoping that we get slowly get to the core of the things.
> 
> Try to work with the existing terms rather than defining entirely new 
> ones.  The concept of "compact" and "rotated" may vary depending on the 
> topology, and is not complete.  "natural", "native", and "map", on the 
> other hand, were pretty thoroughly defined.

I know that I haven't written down an exact definition yet because I'm
trying to understand the problem space. Nethertheless I think that the
storage form should be the compact one.

I think the general idea here is to have something like this (in this
order):

compact form (x*y rectangle)

#####
#####
#####

masked form:

### #
# ###
#####

rotated form (angle can be zero):

### #
# ###
#####

The local operations (also the wrapping) operate on the rotated form
and the global ones (storage, whole_map) on the masked form.

Note however that you don't need different coordinates for these
forms. The form only defines the semantic of the functions.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Two OS engineers facing a petri net chart:
        "dead lock in four moves!"