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: Thu, 25 Mar 2004 20:42:53 -0800
Reply-to: rt@xxxxxxxxxxx

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

>>mediocre.  However we can preserve pixel granularity with the following 
>>operation:
>>
>>   int gui_to_overview_pos(*ovr_x, *ovr_y, gui_x, gui_y)
>>   {
>>     int guinat_x, guinat_y;
>>     const int size = NORMAL_TILE_WIDTH * NORMAL_TILE_HEIGHT;
>>
>>     gui_to_guinat_x(&guinat_x, &guinat_y, gui_x, gui_y);
>>     *ovr_x = guinat_x * OVERVIEW_TILE_WIDTH / size;
>>     *ovr_y = guinat_y * OVERVIEW_TILE_HEIGHT / size;
>>   }
>>
>>AFAICT there is no way to achieve a similar result without the use of 
>>gui-native position.  This is the reason I said in my second e-mail that 
>>I prefered the gui-native solution.
> 
> I don't know what you are saying here or what your problem is. What
> are you trying to do that is so stuffed up it has to be done in one
> way only?

The problem is that when you scroll to the left (in iso-view with an 
iso-map) the overview viewrect zig-zags through the overview.  The 
viewrect doesn't need to be perfectly accurate (since overview positions 
aka native positions aren't that accurate anyway) but it at least needs 
to be *consistent*.  The current behavior isn't.

I don't see how you can solve this problem as long as you go through map 
positions.  One problem is that gui_to_map_pos loses pixel granularity 
so some accuracy is fundamentally lost.  A bigger problem is 
mapview_canvas.tile_width is not very accurate and will consistently 
give off-by-one problems.

>>2.  With a sliding mapview (see PR#8210) we need a gui_distance_vector 
>>function.  This can be implemented via gui-native coordinates or via a 
>>conversion to map coordinates.  The former is nearly identical to 
>>map_distance_vector:
> 
> What is a gui_distance vector used for? At what granularity does it
> measure? Why?  Maybe the example will clarify what concept is not
> clear or being overloaded incorrectly.

Take a look at PR#8210.  gui_distance_vector returns the shortest vector 
to follow to get between two GUI positions.

> Gui coordinates should only be used in the mapview windows which are
> fixed FlatEarth rectangles with no wraps. A backing store is drawn
> into a similar but not necessarily the same sized rectangle depending
> on how you want to cache extra tiles around the current view to limit
> the number of backing store redraws. The full 3x3 map space is an
> upper bound on how big this FlatEarth would ever be.

But this doesn't solve the problem of the sliding mapview.  When the 
player centers on a tile already in the mapview the vector is obvious. 
(Just the difference between the current center and where the player 
clicked.)  But when the player clicks on an overview tile how should the 
mapview slide?

jason




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