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

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

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.

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.

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

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.

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