Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2003:
[Freeciv-Dev] Re: (PR#4648) how to do wrapping in map_to_canvas_pos?
Home

[Freeciv-Dev] Re: (PR#4648) how to do wrapping in map_to_canvas_pos?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#4648) how to do wrapping in map_to_canvas_pos?
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Jul 2003 19:35:39 -0700
Reply-to: rt@xxxxxxxxxxxxxx

Gregory Berkolaiko wrote:
> On Tue, 22 Jul 2003, Jason Short wrote:
> 
> 
>>map_to_canvas_pos must first wrap the given map position relative to the 
>>mapview origin, then convert that to a canvas position.
>>
>>It is the wrapping that is tricky.  The obvious logic is something like:
>>
>>   if (map_x < map_view_x0) {
>>     map_x += map.xsize;
>>   }
>>
>>and this is basically what is currently used for both iso and non-iso 
>>views.  But this isn't quite right for iso-view; for instance 
>>(map_view_x0,map_view_y0-2) will wrap to itself and will never be shown, 
>>no matter how large you make the window.
>>
>>When we allow north-south wrapping and iso-maps this becomes 
>>exponentially more complicated.
>>
>>One alternative is to do the wrapping explicitly, as is done above. 
>>Ross has written a function to do this for gen-topologies, called 
>>unnormalize_map_pos.  It is very complicated.  See the attached 
>>unnormalize_map_pos.c.
> 
> ugh, took me about 1/2 hour to digest it.

Indeed.  The math isn't actually that complicated (it's just a linear 
algebra transformation), but it doesn't translate well.

>>Another alternative is to use map_distance_vector to find the 
>>representative position "closest" to the center of the mapview window, 
>>and use that position for the calculations.  This means 
>>map_distance_vector must be able to deal with unreal positions, as 
>>map_to_canvas_pos does.  See the attached map_to_canvas_pos.diff (this 
>>patch fixes the "not quite right" part of the current implementation).
> 
> 
> I do not understand why map_center_[xy] should stay unnormalized?
> Let them be normalized, it should work just as well.  It would save you 
> from removing CHECK_MAP_POSs, although you can do that to save time.

No, the whole point is that you are looking for an absolute (non-wrapped 
or "unnormalized") position.

First consider that the center tile might not even be real.  If we do 
things right, though, this shouldn't happen...

But consider an 80x50 map with standard wrapping, non-iso tileset.  Say 
x0=70 and the mapview window is 22 tiles wide.  Now the center tile is 
at x=81 or x=1 once it's been normalized.

Now you want to "unnormalize" some coordinates.  Since this example is 
very simple, it should be easy to see the "unnormalized" values should 
have X values in the range [70,150).

Now start with x=1.  It's distance vector has dx=0.  If we use the 
normalized value of center_map_x this will give us an unnormalized value 
x=1, giving canvas_x=-69*NORMAL_TILE_WIDTH - way off the screen.  The 
correct value should be x=81 giving canvas_x=11*NORMAL_TILE_WIDTH.

The basic idea is that the canvas conversion requires absolute 
coordinates - or rather coordinates in a representative set that is 
probably not the normal set.  So we really can't do any normalizing 
operations during the wrapping or we'll just end up with the normal 
value that we started with.

jason




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