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

[Jason Short <jshort@xxxxxxxxxxxxxx>]

--On Thursday, April 10, 2003 11:04 PM +0200 Raimar Falke 
<rf13@xxxxxxxxxxxxxxxxx> wrote:
> 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.
The only form in which these concepts are workable is in map coordinates. 
(adjc_iterate, however, is easy to special-case by changing the DIR_D[XY] 
arrays).
> > > 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?!
Except that I forgot "h", how are they different?

> Also the form you draw here is
> an iso-view of a non-iso map.
This may be a major point of your confusion.  This cannot possibly be an 
iso-view of anything, since it is a non-iso view.
> Iso-maps are rotated in the other
> direction.
Yes, I rotated it in the wrong 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.
Yes.  Both native and index coordinates are compact (aside from masking).

> 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):
>
> ### #
> # ###
> #####
Again you have confused me.  I think you aren't explaining enough.  Are we 
looking at an iso or a non-iso map here?  If it's an iso map, these are all 
the "native" form - which is compact and rotated.
Please define "compact" and "rotated".  Are map coordinates compact?  They 
do not fill a rectangle, but they are not sparse.  There are two separate 
concepts here.   "rotated" has no real meaning, it can only be defined in 
relation to some other form.
So, we have a number of properties:

 - compact: fills a rectangle (ignoring masking)
 - sparse: has gaps (ignoring masking)
 - tile-aligned: preserves the local geometry between tiles

(I just made up the "tile-aligned" name, no doubt Ross has a better name...)

So our coordinate systems have the following properties:

map - non-sparse, may be non-compact, tile-aligned
natural - may be sparse, compact
native - compact, non-sparse, may not be tile-aligned


> 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.
Please explain.

jason