Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2004:
[Freeciv-Dev] Re: (PR#8299) wrapping GUI coordinates
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8299) wrapping GUI coordinates
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 26 Mar 2004 21:56:22 -0800
Reply-to: rt@xxxxxxxxxxx

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

rwetmore@xxxxxxxxxxxx wrote:
> <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 >

Not exactly.  This patch improved some behavior but didn't really fix 
much.  The patch that fixed it was PR#7445.

The problem I'm talking about is different.  When scrolling the mapview 
works just as you'd expect it, but the *overview* viewrect zig-zags. 
This is a different problem that needs a different type of solution.

> 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.

You're going to have to explain a little better than that.

The overview can't use coordinates aligned with the mapview because it 
needs to be aligned with the map.  It would be nice to use natural 
coordinates but this isn't possible (as you've explained before).

So I still have no idea what solution you are suggesting.

>  >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 :-).

Overview coordinates are separate from native coordinates.  The link 
between the two is hidden well behind the interface.

> 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.

This is quite false.  You've multiplied when we should have divided. 
The mapview has a tile width twice that of the tile height.  Meanwhile 
the overview, compressed in the X direction, has an (ammortized) tile 
width half that of the tile height.  This is why the overview and 
mapview don't correspond well at all for iso-maps.

jason




[Prev in Thread] Current Thread [Next in Thread]