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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Hmm, I responded to this before but seem to have lost the e-mail...

Raimar Falke wrote:
> On Thu, Apr 10, 2003 at 02:37:15PM -0500, Jason Dorje Short wrote:
>
> > Raimar Falke wrote:
> > 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.
square_iterate, at least, needs to operate on map coordinates.  Using 
native coordinates will not give anything useful, and using natural 
coordinates is very unwieldy.
None of this depends on the view being used by the client.

> > > 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.
Although I think I have rotated this in the wrong direction, and I left 
off the "h" column, it is otherwise the same map.  I am dyslexic when it 
comes to these rotation operations...
But when you say "this is an iso-view of a non-iso map" I think you are 
missing something important.  This cannot be an iso-view of anything - 
the geometry is wrong.  It is inherently a non-iso tile representation.
> > > 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.
compact == native?  please define it.

> 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):
>
> ### #
> # ###
> #####
How are any of these different?  What does "rotated" mean?  Rotated 
relative to what?
> Note however that you don't need different coordinates for these
> forms. The form only defines the semantic of the functions.
Please explain.  If you're saying that the three forms above are 
identical, well then I agree :-).  Otherwise I don't understand.
jason