[Freeciv-Dev] Re: update for isometric scrolling problem (PR#1222)

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

At 06:39 AM 02/01/20 +0000, Vasco Alexandre Da Silva Costa wrote:
>On Sat, 19 Jan 2002, Ross W. Wetmore wrote:
>
>> Most of the GUI code handling is done in canvas/pixel coordinates. There 
>> really isn't a map_to_GUItile_pos() function anywhere, at least not until 
>> the recent map_to_iso_pos(), it is just
map_to_canvas_pos()/get_canvas_xy().
>> 
>> But at the same time, the granularity of the GUI view is really tile
>> based through NORMAL_TILE_WIDTH/NORMAL_TILE_HEIGHT (or some /2 or /4
factor 
>> of these if one needs to be picky).
>> 
>> For example, (currently) the topleft window corner is always at a tile 
>> origin point (+/- pickiness), and (mapview_x0, mapview_y0) are tile
>> granular. The overview is also fundamentally tile granular.
>> 
>> When you get into mismatches between the view and the native map, then
>> rotated rectangular windows don't fit nicely into the corners of an 
>> unrotated rectangular map. Thus there has to be some spill over that
>> needs to show black tiles where the view extends outside the map.
>> 
>> In any event a lot of the drawing is tile based and one wants to know
>> how many extra tiles out one needs to go to make sure that all the
>> edge effects, i.e. tile overlaps, are properly accounted for.
>> 
>> Thus there seems to be a real need to deal with some level of granularity 
>> above pixel.
>> 
>> So ...
>> 
>> Are you suggesting the entire GUI needs to deal with things exclusively
>> on a pixel basis, for example, topleft needs to have pixel granularity,
>> or what specifically is the (TM) feature that you are looking for here?
>> 
>> Cheers,
>> RossW
>> =====
>> 
>> [ No promises until what you are suggesting is clarified, but somethings
>>   along this line would not be that difficult to do :-]
>
>Yes. That is what i was talking about. The topleft should have pixel
>granularity. We must deal with things on a pixel basis.

Topleft primarily establishes the relationship between a position in
map coordinates (tile granular) with the origin of the GUI window.
Topleft *is* a position defined in map coordinates - the canvas position
it corresponds to is (0,0).

Can you explain a little more about how a pixel granular Topleft would
be intended to operate? What would it do?

>The map canvas has a variable size and this size varies in pixels. 
>Why are we pretending it is a well behaved rectangle that is always a
>multiple of the tile size? This is the root of many bugs and oddities in
>the map view.

Actually, the corecleanups doesn't. It draws more tiles into the backing
store than the window can actually display. Or to put it another way, it
deals with a virtual window that is slightly bigger and offset from the
visible canvas - it worries about top and left, but not a lot about bottom
or right. There is a natural clipping that takes place at the last stage, 
but not a lot of dependence on the visible GUI window size during all the 
processing steps.

Jason's find_representative_map_pos() however does follow more closely
the current code and pushes GUI window dimensions further down into the
lower level operations. This will cause the problems you allude to when
dealing with partial tiles or whatever in coordinate systems that don't
understand such things.

It is possible in blitting from backing store to active window to do
pixel offsets without any real difficulty. One needs to be careful that
mouse clicks use the same pixel offsets when translating back to map
coordinates, or bad things happen. This is pure GUI stuff and would 
change none of the other code in the corecleanups though. Does this 
satisfy your concerns/issues?

But questions arise - would you want to see a sharp linear edge in one
of the isometric views, or have tiles displayed along their natural
(zigzag) borders at the window margins.

What is the real value in pixel granularity? Is it aesthetics, or are 
there some technical problems not mentionned above you think this 
addresses? Can you give a specific example or two?

>We must treat the problem in this fashion: the "map_canvas" is in pixel
>coordinates, and the "map" is in tile coordinates.

When doing anything with the canvas like drawing, this is the case. But
the backing store is tile aligned on the top and left borders, and tiles
are drawn into this in ways that keep overlapping bits from being
overwritten, or written twice, etc, etc. Do you see these sorts of
processes changing?

>The coordinates must be translated between these units by a set of
>functions. The code should use this set of functions everywhere instead of
>doing this ad-hoc like it is doing right now.

This is pretty much the case currently, and certainly one of the goals.
Both Jason's general-topologies and the code in corecleanups have done a
fair bit of consolidation and algorithm pruning.

For the most part, it is a level above simple coordinate transformations 
where certain things like determining the range of the scrollbars is not 
a simple value, or something one measures in canvas coordinates, hence 
the basic units or granularity are not pixel based. Typically, there are a 
series of steps taken and different parts of the code doing similar things 
are taking different ways or orderings of the steps in their particular case.

As some of these places are found and code aligned with sibling spots,
there will likely be another layer of abstraction with core functions
that these places then use.

>---
>Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa

Cheers,
RossW
=====