[Freeciv-Dev] Re: topology RFC (again)

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

I think you are falling back into non-constructive mode :-).

Seriously, there is a conceptual hurdle or two that you just aren't
clearing. Once you figure out how to see things from a slightly
different viewpoint, much of this will make more sense to you. Then
maybe there can be a move towards a real solution rather than this
promotional sales mode you are in :-).

At 01:25 PM 01/11/12 -0500, Jason Dorje Short wrote:
>"Ross W. Wetmore" wrote:
>> 
>> Just to correct the minor misunderstanding ...
>> 
>> "native iso maps that are rectangular in iso coordinates" refers to
>> the map topology, or maybe I should have been more careful to add that
>> in native iso maps, the wrapping vectors are aligned with rectangular
>> map dimensions in iso coordinates. The natural rectangular GUI window
>> then trivially displays iso with none of the odd dislocation of having
>> a map edge running at 45 degrees. Of course with such a natural iso
>> topology, trident tilesets will be the odd case :-).
>> 
>> About coordinates ...
>> 
>> You should always pick the coordinate system to work in to make life
>> easy, and transform in and out of it where needed. But this doesn't
>> mean that you can't do all your mundane arithmetic in one special one
>> if that is the way you find it easiest.
[...]
>Using isometric coordinates to "natively" represent isometric maps is
>very cool-sounding, but I think you are misjudging the difficulties and
>advantages involved.

Are you still confusing coordinates with topplogy? 

Native iso maps can be represented in any coordinate system, but their
native topology doesn't change. For example they still have rectangular
wrapping vectors even if these are at an angle to some other cartesian
system axes. And the GUI still wants to display with *its* cartesian axes
parallel to these wrapping vectors, not to any arbitrary coordinate axes.

>For advantages, how is it really any better to do a "translation" from
>memory to game coordinates on each whole_map_iterate than it is to do a
>check for is_normal_map_pos?  It is no less tricky, and probably not any
>faster either.

Wrong on both the last two guesses.

For one, the iteration is more than twice as effective as your regular
system, it loops over the appropriate topological subset rather than 
some arbitrary selection space that is never less than half populated
and decidely non-intuitive. In both the standard and iso native modes, 
looping in concert with the wrapping vectors is what map, topology and 
GUI all want to do. 

For a second, coordinate transformations are usually simple arithmetic
operations. Your is_normal_map_pos() can start to get horrendously
complex as you try to determine if random points lie in arbitrary shapes.
This is better done by thinking things through up front, i.e. once at
compile time, and not forever after at run time.

For a third, if you will note, this is the same strategy and virtually
the same implementation used for all layered transformations. Each layer
is kept separate and used to handle the operations native to it. This
means that if one wants to add a new GUI flavour at the top, or a 
different topology, all that is needed is to write the layer and hook
up the interfaces on either side. There is none of the cross product 
headache of trying to fit arbitrary shapes into some "regular" system
or propagate some base coordinates into significantly different GUI
perspectives. A monolithic one size system top to bottom is actually
far more complex that a series of linked layer modules. This lesson
always needs to be relearned through experience though :-).

I think too you really do confuse coordinates and topology.

It is not actually that you have to use a different coordinate system at 
each level in the implementation. Keep everything in one grid if you
like, but *think* about each layer and implement it in its natural way
and do the coordinate representation as the final step before 
implementation if needed.

When you do this, you will probably find yourself using the native
coordinate system for the layer more often than not. Your suggestions
on how to do simple nested for loops in a skewed vs native system
probably should have convinced you of this point. It is a pity you 
chose to try and simplify things by taking the wrong direction and
fixing up your mistake with expensive, complex filter functions.
Getting you to let go of this is now more the problem than the actual
technical issue.

>For difficulties - if some game coordinates use isometric coordinates
>and some use flat map coordinates, then there will be great confusion
>and high potential for bug-causing mistakes. 

If you go off doing ad hoc programming, yes. But the exercise for the
last several months is to locate and clean all this up to work through
well defined interfaces. If you learned the lessons, there is no real
problem practically or conceptually.

> On the other hand, if all
>game coordinates are isometric coordinates (that is, if all game
>coordinates are "native map coordinates", which for iso-rectangular maps
>is isometric coordinates), then a large amount of work will be needed to
>make all code conform to this convention. 

Why?  

Sounds like you just haven't looked at things and are just fear mongering
a little to avoid the prospect ...

> This will not just be a
>matter of changing the DIR_DX/DIR_DY arrays, but of fixing
>adjc_cartesian_iterate to use them, 

A few lines of code in a header, and if you do it right, you don't
even have to remove the existing implementation, just add the new.

>changing square_iterate and all
>citymap iterators to convert from flat coordinates (which is really what
>it must use) to "game" coordinates, 

Why? 

All you need to do is fix map_to_citymap() and the reverse. These
iterators already work in citymap coordinates (separate from game 
coordinates) for most things, so why change this?

Square iterate is just special case of a whole_map_iterate. The 
generalized macro is block_iterate. However, if you implement this
as looping over all regular coordinates filtering for those within 
the square, it probably will look a little silly. This should tell
you something about the whole_map solution if you think about it.

>and (hardest of all) changing all
>locations in the code that manually move in one direction to use the
>DIR_DX/DIR_DY iterators as well.

You mean (completing any of) the mapstep() changes? 

>In summary, I think this change is really not worth the trouble at this
>time.  It's way too ambitious. 

I think the hacks to rename every map.xsize, map.ysize loop and operation
so these can be used for "regular" coordinates is a far more extensive
and troublesome change. Then you need to figure out how to reprogram
all these spots to work in some skewed replacement coordinates. 

> At some later point it may be desirable
>to allow the map to be any arbitrary graph, 

What is suggested as far as a layered approach is no where near as
comprehensive as trying to do an arbitrary graph. And since I have
no idea what you htink that means, it clearly can't be the motivation.
Such misrepresentation is unbecoming, and if you need to do this your 
arguments are pretty weak.

It seeks to handle rectangular wrapping topologies in either standard
or iso modes, and handle the memory/map/citymap/GUI operations through
clean interfaces rather than as a jumble of monolithic special cases.
These interfaces are largely defined by <coord>_to_<coord>_pos 
transformations, most of which are already in the code and should be
used without massive or cosmetic change.

>subject to the constraints
>of the GUI (as Reiner has suggested), but the amount of work necessary
>to do this is much larger than the simple changes necessary to achieve
>simple cartesian-grid maps. 

The thought might be, but the work really isn't :-).

> Or, to put it another way, since the client
>must use cartesian-grid ("flat") coordinates anyway, why go to a lot of
>trouble to use something different for the "game coordinates" used by
>the core code?

First the client GUI code needs to work in GUI coordinates, and as
has been said time and time again, these are not the same topology
as the map coordinates even if there is a nice one-to-one mapping
for special cases where things lineup. So the GUI *never* works
in game coordinates except in broken implementations.

More usefully, a simple transformation is easy to program when you need 
to move from one to the other, but trying to do all the work in oddball 
skewed cartesian grid coordinates for both the GUI and map when in fact 
both of them really want to be in a system in which their axes and the
wrap vectors are aligned with normal cartesian axes doesn't make
things very easy, either to build or maintain. 

Your argument is good but you are on the wrong side :-).

If as you say everyone wants flat cartesian grid coordinates, why are
you so insistent in hanging onto the skewed iso-representation, and
looping over some coordinates that have no relationship to the natural
rectangular map shapes or the natural rectangular GUI window?

>jason

Cheers,
RossW
=====