[Freeciv-Dev] Re: (PR#4648) how to do wrapping in map_to_canvas_pos?

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

Jason Short wrote:
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>Jason Short wrote:
>>>Gregory Berkolaiko wrote:
>>>>[jdorje - Thu Sep 25 20:34:03 2003]:
[...]
>>>>Just to remind ourselves what your algorithm does:
>>>>1. find the coordinates of the canvas centre
>>>>2. find the closest representation (because of wrapping there are many
>>>>representation) of the given tile to the canvas centre.  The closest is
>>>>calculated wrt real_map_distance (aka max norm)
>>>>3. convert the coordinates of this representation to the canvas coords.
>>[...]
>>>>I think it will fail in the case of standard rectangular coords with
>>>>x-wrap and the iso-view clients.  Attached is a picture illustrating it.
>>>
>>>Yep.  Note that unnormalize_map_pos will also fail in this (or similar) 
>>>situations. 
>>
>>I don't think so. It certainly does much better because it guarantees
>>all of the tiles Gregory is concerned about are included in the view.
> 
> This depends on the alignment of the mapview.  If we have an X-wrapping 
> map and an iso-view, then with this diagram the dotted tile will be 
> correctly wrapped by unnormalize().  But if it's an X-wrapping iso-map 
> with standard view, it will not.

You haven't figured out unnormalize yet. I think you are projecting your
problems with map distance vector onto unnormalize which does not have
those shortcomings.

> Unnormalize can only detect when a tile is off to the left or top of the 
> screen, not when it's off to the bottom or right.  So it's only slightly 
> better than the distance_vector algorithm.

It does not "detect" anything. It has a fixed mapping of standard map
coordinates onto whatever orientation of output view (aka map_view if you
so choose) you want. It will map the tiles in such a wy that they are
aligned with the view axes in the most compact representation possible
extending to the right and down (assuming the origin is NW (0,0)).

If a tile is out of the view on the right and down direction, there is
no "empty" tile within the view that would correctly display it - unless
you stretched the view abnormally in a direction so that it contained
"candycane" locations, i.e. those that are wrapped by more than a single
adjacent displacement.

To explain pictorially, in the diagram below, X represents a complete
native normal set/view of the map, i.e. map.xsize x map.ysize in extent.

        1 2 3 .
        4 X 6 .
        7 8 9 .
        . . . .

Any map_view no matter which orientation which has its origin in X and
does not extend more than a single wrapping in any direction will be
handled with all possible tiles shown by unnormalize. map_views which
were abnormally stretched to cover more than a single map wrap will
have points in for example the dotted region which unnormalize will not
show even if they could find a valid location within the window. But
because these are more than a single wrap, they give a screwy perspective
of the map that is "candycaned". Things like moving off the north edge
of the map can see you enter at the south middle and then at the other
edge southside if you keep going north. There may be more than one such
location within the mapview window and there are nasty considerations
about which one should be shown.

Unnormalize actually solves the latter problems and keeps things sane
by ensuring that only coordinates from adjacent normal sets as in the
picture are ever used. Thus the map is continuous in a shortest distance
sense between all locations.

> Of course none of this matters in 99% of cases, since the mapview is 
> smaller than the map.  These are soft errors, and a difference in degree 
> is not something to fight over...as long as we allow soft errors to 
> exist at all.

Except that your method as Gregory shows does not even handle all cases
where the view overlaps within a single wrap. You only pickup "closest"
in a native sense and not in the mapview sense, unlike unnormalize that
gets this right, as it aligns things to the mapview axes, not just the
native ones.

>>Remember unnormalize has a normal set that is aligned with the view axes,
>>and thus fits into all the square corners of the view as compactly as
>>possible. Unnormalize only fails to include coordinates that are
>>"candycaned", i.e. the view is distorted so that one axis is elongated
>>to multiple regular or bounding box lengths. And we have agreed that
>>these views should be outlawed because of the oddball effects they cause.
> 
> I'm pretty sure only you agreed on that.

You certainly agreed that candycaning results in a very confusing user
representation, and many implentation issues. That you were fascinated
with these effects from a theoretical perspective early on was also true,
but I think you did come round to the unnecessary complexity view as a
practical consideration in the end. I could post the archived exchanges
if necessary, but don't think that is worthwhile.

>>>But both will show all tiles if the mapview window is 
>>>sufficiently large (which is not true of the current code), and will 
>>>work just fine for sufficiently small mapviews.
>>
>>Agreed as far as unnormalize(), but I am not sure I have seen any clear
>>picture of just how your example fills in the view, i.e. something
>>corresponding to the ones that showed the geometrical wrapping and
>>resulting normal set mappings for unnormalize().
> 
> Huh?  The definition of map_distance_vector guarantees it; no diagrams 
> are necessary.  However, Greg's diagram shows things pretty perfectly. 

Except I think you had some rounding issues that duplicated a few of the
border points. Don't know if you have cleaned this up in recent versions.

If you try to satisfy Greg's concerns and mor fully populate the map_view
you will have to address the normal set constraints explicitly.

> The only difference in the representative set being used from that 
> provided by unnormalize() is that the distance_vector algorithm doesn't 
> take into account the orientation of the mapview. 

Now we are getting at the meat of things. The whole purpose of unnormalize
is to give you the picture in the output aka mapview frame as positive
offsets from its origin.

Map_distance vector misses those points to the left and up, i.e. negative
displacements relative to the mapview frame of reference, since it works
only in the native coordinate space or the input coordinate system.

Greg is interested in the output view, so you don't satisfy him with your
algorithm.

> If you recall, the 
> originall implementation of unnormalize() didn't do this either, but 
> since it is aligned to the origin of the mapview this meant some tiles 
> weren't shown. 

It is the reverse. If you don't consider negative displacements in the
mapview frame, you miss tiles. Unnormalize has pretty much always done this
except for *very* early flavours that were basically the quick first cut at
the map_distance level of consideration. As soon as it was used for GUI
displays vs core calculations, it was cleaned up.

There is or was a comment left in map_distance() at one point to remind one
of these missing cleanups, but as it was only being used for core purposes,
there was no need to consider the problem. In fact it would give bad results
for shortest distance, because it would pick the (longer) distance that was
positively offset and hence *in* the mapview window, rather than the negative
one that was *not*.

As I have said, map_distance() is not the right tool to use for these
purposes, as it isn't designed for this and the fixes essentially convert
it to unnormalize with some options for retaining shortest distance for
core needs.

> In other words, unnormalize_map_pos _has_ to align the 
> representative set with the mapview, whereas map_distance_vector does not.

Right, but as usual, you recognize the point but make the completely invalid
interpretation, somehow rationalizing that it is good and reality bad :-).

By choosing the output view in the arguments to unnormalize you can have it
handle GUI skewed output windows or core windows where the axes skew is
missing. The argument choice gives you the flexibility to do it all.

For someone who just sees your claim that this is right or wrong without
working through the underlying logic that you have gotten wrong, it can be
very confusing, I am sure.

> jason

Cheers,
RossW
=====