[Freeciv-Dev] Re: Topologies and coordinates

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Andrew McGuinness wrote:
> 
> Quoting Jason Dorje Short <vze2zq63@xxxxxxxxxxx>:
> 
> > Andrew McGuinness wrote:

> > > 3  Displaying the map, in such a way that displayed adjacency is
> > >    correct, and the orientation of the map is sensible
> >
> > No, this can use identical methods to those above.  However cleaning up
> > the GUI so that this will work will be a major undertaking.
> >
> 
> At the least, the gui needs to know whether the north pole is at y=0
> or at x-y=K

Why?

What if a torus map chooses not to have a north pole?

> > > Depending on how you translate the topology onto a grid, some of those
> > > might go away.
> > >
> > > The priority is a simple civII-style map, with isometric view and the
> > > poles at the top and bottom.  I call this a "diagonal" map
> >
> > We've been calling it isometric.
> >
> I avoided that because of the confusion between isometric view of an
> isometric map, and isometric view of a rectangular map (what we already
> have)

Sensible.  How about "iso-rectangular"?

> > >
> > > Any of the three could work.
> >
> > Not really.  If we want to keep our current structures (and avoid HUGE
> > amounts of extra work) only map#1 will work.  It is the only one that
> > has been seriously proposed.  Raimar proposed some sort of mapping from
> > mapspace to userspace, but I don't think he had thought it out fully.
> >
> > Remember that we don't just look at adjacent positions; that would be
> > headache enough in itself.  There are lots of square_iterate macros that
> > iterate over vision range, city range, etc.  Converting all of these
> > makes #2 or #3 infeasable.
> >
> > In short, map#1 is the right way to go; there is no doubt in my mind.
> >
> I think you are right.  I was concerned because in your discussion with
> Raimar, small implementation details were obscuring the issues (at least
> from me)  I was trying to get back to the fundamentals.

A number of assumptions were made in discussions a while ago; I guess
they haven't been hashed out recently.

> > Yep, you understand.  However you are unnecessarily linking the wrapping
> > information to the topology.  Either rectangular or iso-rectangular
> > topologies can wrap in north-south, east-west, both, or none.
> >
> Yes, but the semantics of normalise_map_position, and also of things like
> get_distance_between (or your get_vector_between) and the like depend on
> both the alignment (rectangular/iso-rectangular) and the wrapping
> behaviour.

What do you mean by "semantics"?  Internally, the functions will need to
be extended but I don't see that the function will be used any
differently.

> > > This is the discussion that has been going on - whether it is general
> > > enough to assume that:
> > > >From (x,y) any tile ( x +/- 1, y +/- 1 ) is either
> > >  a) a valid tile adjacent to (x,y)
> > >  b) wraps to another tile (r,s) which is adjacent to (x,y),
> > >  c) is invalid
> >
> > You cannot ever assume this.  However, you *can* assume that
> > normalize_map_pos will tell you everything you need to know (assuming we
> > use map#1).  The problem is most of the code doesn't use
> > normalize_map_pos.
> 
> Well, that's what I meant - normalise_map_pos will tell you whether
> a,b or c applies, and in case b what the real coordinates (r,s) are.

Right.  Of course, most code doesn't care about the difference between
(a) and (b), and in fact you have to do extra work to tell which is the
case (normalize_map_pos doesn't tell you, you have to compare
coordinates before and after).

> If map#2 were used, on the other hand,(x-1,y-1) might be a valid tile
> which is not adjacent to (x,y) - that's why it's not a good idea.

It's a big drawback.  It would require large amounts of rewrites.

> > > The tradeoff is between generality and performance - having to use
> > > get_adjacent_tile() rather than the current iterate_xy macros would
> > > slow things down a bit, and it is not essential to implement the
> > > new topologies we really need.  On the other hand, not using it does
> > > restrict the wierd and wondeful topologies people might want to play
> > > with.
> >
> > As I said before, the current macros will work just fine (although they
> > too need to be fixed up a little bit).  There will be some slowdown
> > because the extra check for topology will be added, but this is
> > absolutely insignificant.
> 
> Yes, your plan is the faster but less general one. There are options that
> you could have only if you don't assume that normalise_map_pos is all you
> need.  Playing on the surface of a cube, for instance.  That definitely
> comes under "wierd and wonderful" rather than "what we really need". It
> would also be very difficult to display, compared to the other systems
> we have been talking about.

It *might* be possible to do more.  I think, though, that using map#2
wouldn't really help you...what you're talking about is basically an
arbitrary graph of nodes, which topology interface functions to ALL of
the transformations.  This would allow you to do any kind of map you
want.

I have assumed that all topologies will map cleanly onto a plane.  The
multi-cube one does not.  How will the client display this map?  I've
seen discussion on this, but nothing satisfactory.  Ultimately, the
client will display only a plane.  If we assume all topologies follow
this, then (1) the client has no problems and (2) much less work is
needed.

What do you think?

jason