[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Apr 14, 2003 at 11:02:28AM -0500, Jason Dorje Short wrote:
> Raimar Falke wrote:
> >On Sun, Apr 13, 2003 at 05:37:59PM -0500, Jason Dorje Short wrote:
> 
> >>>>If the directions don't even line up with your map, how is anyone
> >>>>supposed to understand what's going on?
> >>>
> >>>I think it is easier to understand one set of coordinates where
> >>>MAPSTEP does a magic thing as multiple sets of coordinates.
> >>
> >>The problem is (1) the set of coordinates is itself very non-intuitive 
> >>and (2) the hacks you have to do to get local operations to work are 
> >>error-prone and non-intuitive.  Better to introduce a single, 
> >>freeciv-wide solution that is easily understandable (explained in 
> >>doc/HACKING) and works for everything.
> >
> >
> >There are certain parts of the code which are topology
> >dependent. These parts are few:
> > - neighborhood relation: can be reduced to MAPSTEP
> > - distance: is reduced to map_distance_vector
> > - wrapping/normalization: is reduced to normalize_map_pos
> 
> None of these are topology-dependent under map coordinates.  So in 
> essence you are saying that these are the only parts of the code that 
> need map coordinates.  

> But there may be more

Quite possible. But finding these on the way is a goal.

> I'm not sure.  Certainly 
> there are some additional (non-mapview-specific) ones in mapview.

> Conversely, if we use map coordinates as standard there are just a few 
> places that need to convert to native coordinates.  These include a few 
> map.c backend functions (normalize_map_pos, map_distance_vector, 
> rand_map_pos, map_to_index_pos, index_to_map_pos) as well as a very few 
> pieces of user code (savegames, map debug output).

So we both say that our changes are minimal.

> > - mapview: is reduced to one file (mapview_common) AFAIK
> 
> Don't just lump in everything in mapview.c and mapview_common.c into 
> "mapview" and write it off.  mapview does have some very specialized 
> needs (like clipping the window), but also some generalized ones as well 
> (like rectangle_iterate).

You agree that all this should and can be done in mapview_common?!

I also said in the past that the mapview_common change won't be easy.

> >So I propose that we change these 4 very isolated pieces of code and
> >don't confuse the general programmer with this. I'm not against doing
> >a transformation to a nicer coordinate system in these pieces of code
> >if this makes the task easier. But these "special task" coordinates
> >will never leave this functions (or file).
> >
> >I'm also for defaulting to the other coordinate system (native and not
> >your new map coordinates). I think that most of the functions are
> >using these (no need to transformation for tile access). And from the
> >4 pieces above MAPSTEP and normalize_map_pos can be done as fast as
> >the current code. And MAPSTEP and normalize_map_pos are the most
> >common of the above functions. So I think that using native
> >coordinates is a speed win.
> 
> This is a reasonable position - using native coordinates as standard and 
> only using map coordinates for needed operations.  The question one 
> would have to answer is: how much harder is it to do this than to use 
> map coordinates as standard?
>
> (I still don't see why you believe your method requires fewer code 
> changes.  This may be true, but there is no evidence for it.)

Let me create some code so that we can have some facts. Hopefully this
week.

Is there an implementation of your approach which is complete? For
measure of speed and general impact this doesn't have to support
mapview.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Real Users find the one combination of bizarre
   input values that shuts down the system for days."