[Freeciv-Dev] Re: (PR#3953) Off-canvas coordinates problem

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

Jason gave a pretty complete description of the generalized algorithm.

This is just a couple quick background comments.

Cheers,
RossW
=====

a-l@xxxxxxx wrote:
> There are one or two more issues with map_to_canvas_pos() I think
> need to be addressed, and I'm not quite sure how to go about it.
> This is only about tiles outside of the mapview.
> 
> Issue 1.
> 
> I would like the function to behave so that a tile with a higher map
> Y coordinate always gets a higher canvas Y coordinate.

Perhaps you could give a clear reason why? Or the scenario for which
you think you need this capability?

I would caution you against wanting to fix an association between a
single pair of coordinates in two different systems as a general concept,
but if you can describe the mapping of one set of points into a second
(wrapped) set, it might be reasonable to have map_to_canvas_pos() work
in concert with this mapping. There are in general an infinite number
of ways to map one normal set one-for-one into a second normal set by
wrap equivalent operations, and there may be a way that one can better
pick the second set to overlap with a given canvas.


> Issue 2.
[...]
> So I have to use somewhat special cases when iterating over canvas
> coordinates to determine the wrapping point. (I want to keep them in
> agreement with the canvas coordinates that the function gives for the
> tile they represent, for certain reasons.)

If you are iterating over canvas coordinates, then the simple
coordinate transformation can give you (possibly) unnormalized or
unreal map positions. normalize_map_pos() is then used to detect
the unreal cases or return the usable normalized map coordinates.

You shouldn't *need* to worry about anything else such as where the
wrapping occurs in map coordinates.

If you do have a valid reason for wanting unnormalized coordinates,
it is trivial to split the current function in two and call just the
inner part. This may run into religious arguments about the sin of
using unnormalized coordinates no matter how useful this might be in
certain instances. If you have a valid instance, I for one think it
would liven up the old debate :-).

> Maybe the ideal behaviour of map_to_canvas_pos() would be this:
> For tiles outside of mapview, consider the map's X and/or Y wrapping,
> and determine wheter a negative or a very big coordinate should be
> produced based upon the shortest real distance. To the left or right
> of the monitor?

Going the other way, i.e. iterating over map coordinates and trying
to figure out where to stick them in a floating canvas window is the
hard problem above.

[...]
> Could we have normalize_canvas_pos() ?

Note, you may not get what you are asking for :-).

To sensitize you to the issues, normalization in your terms above is
something that maps arbitrary map positions to a well-defined set of
points - the normal set. The mapping occurs through wrap operations.

Canvas coordinates are *not* map coordinates, but refer to GUI window
coordinates. These describe a different object that has different
topological properties than the map. The GUI window is typically a
fixed rectangle and coordinates do not wrap but are clipped by the
window mask into a real (or valid window) and unreal set.

Normalize_canvas_pos() would give you back the coordinates you gave
it since there is no wrapping operation, and return true or false
depending on whether the coordinates were real window values. This
is similar to a map in the "FLAT_EARTH" topology where there are
fixed edges past which you fall off into some unreal limbo. In the
GUI limbo is a black tile.

> Native canvas coordinates?

Canvas coordinates are pretty much native. The only thing that might
change is scaling, i.e. native canvas -> NORMAL_WIDTH = NORMAL_HEIGHT = 1.

> Arnstein

What you are probably looking for is something that muddles up map
and canvas operations. This is what the current code does, and is
the wrong direction to go if you want a general solution (or even
an understandable one :-).

Try to figure out a model in which you can code the two as completely
independent steps.

For example, if you really need to iterate over map coordinates, and
if your map wraps, then you might think of the surface your GUI window
floats over as a 3x3 set of mirror maps. Figure out the iteration
limits from (-xsize:+xsize, -ysize:+ysize) corresponding to the
GUI shadow on the mirror set (i.e. map GUI corners to unnormalized
map positions). Loop over these *unnormalized* map coordinates,
converting them to canvas or normalized map coordinates as needed to
access data or whatever. The split is to do topological operations in
topological coordinates (actually probably native and not map in the
general case), and convert to memory, call argument or canvas
coordinates when needed for those operations.

You could use the concept of a bounding box and is_real_canvas_pos()
to iterate over a wider set of unnormalized map positions, picking
only those that lie in the canvas window. This is generally a bad
pattern (widely favoured in some circles though), but might have
validity in some instances. It is bad because it replaces thought at
the design stage with CPU cycles at the runtime stage, but can also
lead to all kinds of more subtle issues like showing tiles twice at
different wrap positions.

Cheers,
RossW
=====