Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: (PR#3936) introducing native coordinates
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3936) introducing native coordinates
From: Ross Wetmore <rwetmore@xxxxxxxxxxxx>
Date: Sat, 12 Apr 2003 01:19:29 -0400


Jason Dorje Short wrote:
Raimar Falke wrote:

On Fri, Apr 11, 2003 at 04:11:14AM -0500, Jason Dorje Short wrote:

This makes some sense. But please try to distinguish which map you are representing, and which coordinate system you are using. For instance is a

    THERE IS ONLY ONE COORDINATE SYSTEM. EACH TILE HAS EXACTLY ONE
    PAIR (x,y).

This is different to your idea but I think it makes it easier to
understand. At least for me.

I must say I understand almost nothing of what Raimar wrote. So I
can't really comment on any of it other to say it was unintelligible.

> > 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:
>     1a
>    32#b
>   54###c
>    #####d
>     ##oooe
>      #ooo#f
>       ooo##g
>        #####i
>         #####
>          ####
>           ##
>
> which means that, in map coordinates, the semantics are unchanged from
> the original.

These key diagrams from Jason really do visually show the difference
between thinking in natural and map coordinates. The true-iso map
in the first case is actually referenced in map coordinates as the
second one, i.e. a1 == (2,0) where the origin is the NW corner at a
position under the "3".

The point to note is that the local square_iterate is a simple op to
code in map coordinates, and a very complex one in the natural system.
Thus if you wanted to square_iterate in natural coordinates you
should do something like this instead of trying to write the loop
purely in natural coordinates.

  natural_to_map(&x0, &y0, "4", "c");
  for (map_y = y0-1; map_y < y0+1; map_y++)
  for (map_x = x0-1; map_x < x0+1; map_x++)
  { if (map_to_natural(&nat_x, &nat_y, map_x, map_y))
    { ... code using nat_x, nat_y
    }
  }

Note as well, that the natural coordinates are laid out on a grid
in which all the spaces are "masked" out or "unreal" points which
complicates iteration. There are an equal number of unreal and real
grid points which means the representation is not dense like the
map flavour where every neighbouring grid point is real. The scale
of distances is also off by a factor of two and more complicated to
compute. Compressing the natural coordinates to native form makes
these ops even more confusing.to visulatize or compute. This is
because native or natural coordinates are not designed or suitable
for local operations.

Ahh, well that explains part of the confusion [1]. The problem is, it doesn't work. Your proposal is that we only use native coordinates, but square_iterate and other local functions cannot be implemented in these coordinates. Similarly, global operations cannot be done in map coordinates.

I wouldn't say they can't be done, but rather are done in a much more
complicated and cumbersome manner. Raimar should try writing and then
generalizing this sort of code. Then present a patch that uses it so
we see just what a mess it really is for comparison purposes and how
well it doesn't generalize.

[...]
jason

Cheers,
RossW
=====



[Prev in Thread] Current Thread [Next in Thread]