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

[Jason Short <vze2zq63@xxxxxxxxxxx>]

Ross W. Wetmore wrote:

> I think there are some problems with the isometric scaling additions. 
>
> The two scrollbars are not independent, but constrained by the fact
> that the iso view cannot move to all positions. This is not a problem
> if the scrollbars are handled in standard map coordinates, or maybe
> I should say not as much. This will reverse with iso-maps.
Yes, you can see this problem in iso-view: if you slide all the way to 
the top, the mapview will push against the north pole and you'll have to 
move horizontally to account for it.
There's a comment about this in the code.


> This doesn't seem to take that into account. Moreover since you are
> setting up a new interface, you should pass in both current slider
> positions and deal with things in a proper 2-D fashion.
This would be better, yes.  This might require tracking the slider 
positions separately (from GTK), though; I haven't looked into 
retrieving their values from GTK.

> Technically the scrollbars only have a range of the map size minus the
> current canvas size, or some BB enclosing it.
No: in GTK the scrollbar has a range of the map dimension in a 
particular direction, plus EXTRA_BOTTOM_ROW if necessary.  Then the 
slider itself takes a width of the current canvas size.  This means 
you'll end up with the same effect you have above.
xaw does not appear to work this way, but win32 does.  However, it 
should be possible for the GUI to subtract off the extra value to deal 
with it if necessary.

> The current calculations are also a fairly confusing mess of special
> cases. Again, if one goes to a new set of functions, I think they need
> to be done with some obvious improvements, rather than just generating
> code that now needs ot be fixed again.
The only special case is that it assumes the current dimensions of the map.

The calculations aren't explained particularly well in the code, though. 
 I basically convert the coordinates into native positions, shift them 
to be on the correct scale, and then compress them.  This could be 
accomplished with some straightforward backend topology functions:
  map_to_iso_pos()
  get_min_iso_x()
  get_min_iso_y()
  get_range_iso_x()
  get_range_iso_y()
Note this requires both dimensions, as you describe.  But it is clearly 
a better (topology-independent) way to do it.
This could possibly be extended even further, to compressed native GUI 
coordinates, but that's probably overkill.

> With some more work this might be quite useful.
I think it's quite useful as-is :-).  It will certainly need 
improvements to be workable under different topologies, though.
jason