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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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.

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.

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.

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

>>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. 
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.  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.  In other words, unnormalize_map_pos _has_ to align the 
representative set with the mapview, whereas map_distance_vector does not.

jason