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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Oct 05, 2001 at 10:19:04PM +0100, Gaute B Strokkenes wrote:
> 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.

I think we got everything. There are only some map_adjusts left:
./common/map.h:2
./server/mapgen.c:6
./server/maphand.c:1
./server/settlers.c:2
./server/unittools.c:1

If you know any more instances please tell.

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

See the proposed CHECK_MAP_POS patch.

> > 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

I agree that I think nearest_real_pos is a band-aid.

> , 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Any sufficiently advanced technology is indistinguishable from magic."
    -- Arthur C. Clarke