[Freeciv-Dev] Re: (PR#8299) wrapping GUI coordinates

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

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8299 >


Gregory fixed it. It should be cleaned up (at least comment-wise
to explain why it is not a hack).

   <URL: http://rt.freeciv.org/Ticket/Display.html?id=7384 >


I've added an old exchange that gives a hint to what is really
going on. If you actually fix the overview to use proper GUI
cordinates and do it right, then the "native-is-close-enough"
hacks talked about there all go poof. The question to fix the
old hacked overview until one has the time to do the full split
and GUI system is up to you. In the GUI system get it right and
don't leave any of the residual native abuse.


But the basic problem is the way one defines the order of a y
axis for storing vs the way one wants to do it for scrolling.
Native is not the same as GUI in this case, as the GUI wants to
make things closer to the way the x-axis is double-sized and
somehow deal with the half-tile offsets.

Cheers,
RossW
=====


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8299 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>>There are at least two other GUI topology problems.
>>>
>>>1.  The overview viewrect is inaccurate.  If you play an iso-map with 
>>>iso-view and scroll to the left, the viewrect will zig-zag.  Pretty 
>>
>>Problem thoroughly understood and native bugfix is trivial. Why haven't
>>you applied it?
> 
> What is the bugfix?  Can you point me to a patch or tell me the algorithm?
=====

This is an old exchange that has a lot of the hints.


 >From - Sun Jan 26 11:34:22 2003
To:  jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: map->native positions


We talked about this before, but to recap ...

The scaling of any view has nothing to do with the compression scheme and
everything to do with the GUI window sizing. Don't confuse the two. Don't
build in constraints that link independent things. And don't misunderstand
the current "optimization" of the GUI overview to hardcode the scaling by
forcing this downwards to make the constraint apply to something it has no
relationship to - that just screws up the system :-).

Besides, the scaling *is* better with x compressed rather than y in my
experience. You should remember that Y tiles are half height, so the X
compression effectively makes all overview positions the same size, or
square 2x2 pixel elements which is how they are currently "scaled". If
you don't like this, change the 2x2 display scaling algorithm.

The x direction is also generally signifcantly larger than the y direction.
It is the one "printed" on a line in debug and savegames. Compressing it
makes things much more readable than having extensive line wrap in even
normal cases. Native coordinates are designed to handle these "core"
functions and *not* GUI ones - they are not a GUI level coordinate.

Put another way this makes dimensions "squarer" rather than "skinny".

It also conforms to the standard way that hexagonal and other coordinate
systems label things if you go read the net. To get hex, you do not allow
the N-S y-axis movement that occurs in an octagonal adjacency system.

     4
       3
     2
       1
     0

This is how many of the y-axis numbering schemes look. It corresponds to the
generally northwards movement which you need to zigzag to accomplish. The
x-axis direction on the otherhand is a simple increment as this is a standard
hex axis direction, i.e. plane of symmetry.

You would screwup all this if you changed it. Unconvince yourself :-)

Cheers,
RossW
=====

Jason Dorje Short wrote:
 > As a side note, I'm convinced we should compress native coordinates in
 > the Y direction rather than the X.  Since we currently have the hack of
 > using native coordinates unchanged in the overview, it makes a lot more
 > sense to shorten the y direction since this is how the tileset generally
 > does it.  That is, it will lead to a much better correspondence of
 > overview to mapview - currently the overview appears 4x as "tall" as it
 > should be because of this.
 >
 > jason