[Freeciv-Dev] Re: [PATCH] Formatting cleanup.

[Gaute B Strokkenes <gs234@xxxxxxxxx>]

On Thu, 04 Oct 2001, vze2zq63@xxxxxxxxxxx wrote:

>> > There are some topologies that would not be particularly
>> > difficult to implement for which wrapping of non-real tiles has
>> > no good meaning whatsoever.
>> >
>> >        x x x            
>> >      x x x x x          
>> > <- x x x x x x x ->     
>> > <- x x x x x x x ->     
>> > <- x x x x x x x ->     
>> >      x x x x x          
>> >        x x x
>> 
>> I was referring to <87wv3lu4zr.fsf@xxxxxxxxx>.  I note that the
>> picture that you've drawn here is different from the one that you
>> drew last time, and that the picture you have drawn here represent
>> something that is more sensible than what you drew last time.
>> 
>> [ The difference was that the little arrows extended all the way to
>>   the top and bottom in the previous diagram.  This makes a BIG
>>   difference for the following argument.  ]
> 
> The picture is drawn slightly differently (I thought the previous
> drawing might have confused you), but it's the same topology.

The thing that was different was the little arrows you drew, like
this:

<-     x x x     ->
<-   x x x x x   ->
<- x x x x x x x ->
<- x x x x x x x ->
<- x x x x x x x ->
<-   x x x x x   ->
<-     x x x     ->

I took that to mean that you could sit on top of the map and walk
around the world in three steps, for instance.

But of course, it's NBD now.

> My bad.  It's a bad example.  I've come up with a better one below.
> 
> How about this topology:
> 
>                  ^ ^ ^
>                  | | |
> <- X X X X X X X X X X
> <- X X X X X X X X X X
> <- X X X X X X X X X X
> 
> As far as I can tell (could be wrong), this topology should be valid
> enough (it is not well-oriented,

Orientable.  But we don't need that.

> or whatever you called it, but this is a technical problem not a
> validity one).  Yet there is no conceivable way (well, no good way
> anyway) that you can wrap non-real tiles.

The current underlying assumption is that two coordinate pairs are
considered to be the same if and only if their difference (as vectors
of the Z-module ZxZ) can be expressed as a linear combination of a
given set of vectors.  Currently, that set is {(map.xsize, 0)}.  If we
implement a rectangular topology that becomes the empty set.  For a
torus it would be {(map.xsize, 0), (0, map.ysize)}, and if we implment
an isometric-view cylinder it would be something like {(map.xsize,
map.ysize)} (I didn't check that, but you get the idea.)

Thus if (x, y) refers to a real tile, so must any other coordinate
pair that you arrive at by repeatedly adding or subtracting vectors
from that set.  Corrollary: if (x, y) does _not_ refer to a real tile,
neither does any other coordinate pair obtained by adding or
subtracting vectors from the appropriate set, since otherwise you
would be violating the above.

In short: under the current regime, you will never be able to break
anything by fiddling with unreal coordinates in this manner.

The topology that you have above does not satisfy these conditions.
That doesn't necessarily make it bad, but if you wish to implement it
you will need to change everything that depends on this assumption.
Amongst other things, that means removing normalize_map_pos() and all
calls to it, so it is a bit backwards to use this as an argument to
use or change normalize_map_pos().

A good first step would be to convert as many places as possible to
use MAPSTEP() rather than manually twiddling coordinate pairs and
relying on normalize_map_pos() to clean up the mess.  MAPSTEP() would
still work under such a topology because it works by applying a
direction to a point.  (Currently it uses normalize_map_pos()
internally, but the point is that it doesn't have to.)

Another good thing would be to make sure that as many places as
possible create normalized coordinates at the outset.  That would also
enable you to ditch a lot of normalize_map_pos() calls and replacing
them with some sort of assert.

> I say again: any time you are wrapping an unreal coordinate, or
> doing anything at all to it for that matter outside of converting it
> to a real coordinate, you are doing something fundamentally,
> theoretically wrong.

I'm afraid that it is your reasoning that is fundamentally,
theoretically wrong.

I'm not entirely sure what you mean by "converting it to a real
coordinate".  I assume you mean something like map_adjust_y() or
nearest_real_pos().  If you wish to take most abstract view possible,
this is more wrong than playing games with unreal coordinates, since
there is no particular guarantee that there is a well-defined nearest
real tile in an arbitrarily nasty topology.

> Give me enough chances, and I'll find a topology that proves it.

I consider that unlikely, given my above proof.

But really, I think all this talk about supporting arbitrarily strange
topologies really has that much value.  The only topologies that I
think we really want to support are the rectangular, cylindrical and
isometric-view cylindrical variants.  Additionally, a torus might be
so easy to do that there may well be no real reason not to.  But
everything else, including the stuff that I have mentioned from time
to time (Möbius strip, Klein bottle, RP^2 and so on) really strikes me
as having little value beyond the gee-whizz factor.  Also, since the
greater part of the difficulty would be the creation of client support
(you need to think about how you're going to draw them on the screen
and so on) which I don't see anyone leaping up and down with eagerness
to do, (though I do see people who would be willing to make the [mostly
straightforward] corresponding changes to the core).  Nor do I think
we wish to make the client stuff any more complicated than it already
is just to support this.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
I feel better about world problems now!