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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Gregory Berkolaiko wrote:
> On Wed, 23 Jul 2003, Jason Short wrote:
> 
> 
>>Gregory Berkolaiko wrote:
>>
>>>On Tue, 22 Jul 2003, Jason Short wrote:
>>>
>>>
>>>
>>>>Gregory Berkolaiko wrote:
>>>>
>>>>
>>>>>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.
>>>
>>>
>>>Err.  I don't quite understand the paragraph above.  OUr goal is to get 
>>>canvas positions, isn't it.  So we get distance verctor dx = 0, therefore
>>>     canvas_x = center_canvas_x + dx*NORMAL_TILE_WIDTH
>>>gives the correct answer.
>>
>>It only gives the correct answer if center_canvas_[xy] is unwrapped.  If 
> 
> 
> What do you mean center_canvas is unwrapped.  It's canvas!
> center_canvas_x = mapview_canvas.width / 2;
> center_canvas_y = mapview_canvas.height / 2;

Oops; I meant center_map_x.

>>you normalize it then you'll get something completely different.  With 
>>center_map_x=81 we'll get a position 11 tiles right of the origin, 
>>whereas with center_map_x=1 we'll get a position 69 tiles left of the 
>>origin (which is wrong).
>>
>>This is because the calculation isn't done as
>>
>>   canvas_x = center_canvas_x + dx * NORMAL_TILE_WIDTH
>>
>>but as
>>
>>   map_x = center_map_x + dx;
>>   canvas_x = NORMAL_TILE_WIDTH * (map_x - map_view_x0);
>>
>>the former method is possible but means more changes (particularly for 
>>iso-view).
> 
> 
> So use the former method, it is more transperent, I think.

I take it back; the former method (your method) won't work.  The reason 
is that

   canvas_x = center_canvas_x + dx * NORMAL_TILE_WIDTH

won't work because center_canvas_x is not the tile origin of the center 
canvas position - in fact the only reliable way to find the origin of 
the center tile AFAICT is to use map_to_canvas_pos, which we can't do...

A long-term alternative would be to change (map_view_x0,map_view_y0) 
(i.e., the canvas origin) to be the center tile rather than the top-left 
tile.  Then all calculations would be done relative to the center of the 
canvas.  In fact this would make a lot of calculations easier...

>>As a side note, (map_x, map_y) may be unreal and so map_distance_vector 
>>has to deal with unreal positions in either case.
> 
> 
> It should be, otherwise more than 50% of the window is black.

(center_map_x, center_map_y) should never be unreal, but (map_x, map_y) 
often is.

>>>Another issue is that I am not 100% sure your approach will give the right 
>>>answer for iso tiles.
>>
>>I'm pretty certain it does.  You can try using iso-view with a 40x25 
>>map.  If you enlarge the window sufficiently you will be able to see the 
>>whole map, approximately centered around the center.
> 
> 
> I'll think more about it.

The concept is exactly the same as for non-iso mode; you find the 
position "closest" to the center tile and draw that.  The only bad thing 
is you leave it up to map_distance_vector how to define "closest" (but 
this is no problem since it is mostly well-defined).

jason