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: Sun, 27 Jul 2003 20:53:41 -0700
Reply-to: rt@xxxxxxxxxxxxxx

rwetmore@xxxxxxxxxxxx wrote:
> I'm not sure what the problem with unnnormalize_map_pos() really is,
> but let me try and relate all the normalize/unnormalize/map_distance
> algorithms and how they reflect special case/optimizations of the
> general case reflected by unnormalize_map_pos() as a primer.

The core problem, I think, is that unnormalize_map_pos not only does the 
unnormalization but does it into a set of specified choosing (e.g., iso 
or non-iso) - which simply isn't worth the extra complexity.

If you get rid of the is_iso parameter things become much simpler:

   bool unnormalize_map_pos(int x0, int y0, int *x, int *y)
   {
     int nx, ny;

     map_to_native_pos(&nx, &ny, *x, *y);

     if (map_has_wrapx()) {
       nx = x0 + WRAP(nx - x0, map.xsize);
     }
     if (map_has_wrapy()) {
       ny = y0 + WRAP(ny - y0, map.ysize);
     }

     native_to_map_pos(x, y, nx, ny);

     return is_real_map_pos(*x, *y);
   }

the only drawback is that if you use the mapview origin as the (x0,y0) 
point there are some tiles that will never be drawn for some topologies.

Originally I thought the solution was to provide the is_iso parameter. 
This does indeed fix things, but it makes the math much harder.  (As a 
side note, if we were ever to draw tiles multiple times this would 
probably be the only/easiest way).  Instead I think the solution is to 
base the unnormalize off of the center tile of the mapview.

That said, map_distance_vector is exactly the same operation as this 
unnormalize - but the origin it is given (x0,y0) is taken as the center 
position of the "un"normal representative set, and the value returned is 
a vector from this position (*dx,*dy) rather than an absolute position. 
  Conveniently enough, this makes its usage in map_to_canvas_pos simpler 
than it would otherwise be.

jason




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