[Freeciv-Dev] Re: topology RFC (again)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Oct 28, 2001 at 03:10:58PM -0400, Ross W. Wetmore wrote:
> [...]
> >*** 1c.  Current Operator Functions
> >
> >The following functions are necessary to do operations and checks on map
> >positions.  All should work under the arbitrary topology discussed
> >above.
> 
> It is worth stressing that these are functions that apply to "map" positions 
> or gaming coordinates. 
> 
> It is in general meaningless to feed them arbitrary coordinates, GUI or 
> citymap coordinates for instance. 

> There may be corresponding functions which do take GUI or citymap
> coordinates

There will no special citymap functions. All citymap can and should be
transformed to map positions.

> , and in the simple case where 
> all are rectangular coordinates related by simple translations, they may 
> in fact have similar implementations. 
> 
> *** IMPORTANT *** SIMILAR IMPLEMENTATION DOES NOT MEAN SAME CONCEPT
> 
> This is going to be a very difficult point for the literal minded :-).

> To make this clear, consider the case where gaming coordinates are polar
> coordinates of the form (r,theta). This would perhaps be useful to play
> on a solar system map. GUI coordinates could still remain as rectangular
> positions, i.e. the pixel or scaled pixel coordinates used by GTK or XAW.
> r is non-wrapped with bound map.rsize, theta wraps at its equivalent of
> 2*pi.

Uhhh. 

> >- distance_from_pole(x, y) returns the distance from (x, y) to the nearest
> >pole (0 for none).  This will most likely be a topology-independent wrapper
> >to another set of functions, but the exact nature has not yet been decided.
> >See the mapgen discussions below and on freeciv-dev.  "Distance" is poorly
> >defined.
> >
> >- distance_from_edge(x, y) may return the distance from (x, y) to the nearest
> >edge (0 for none).  An "edge" is a position that has an adjacent unreal
> >position.  "Distance" is poorly defined.
> 
> Any such functions are almost certainly highly specialized to things like
> map generation for a particular topology/worldview and should be left as 
> local implementations in such special generators until there is a real need 
> for them in more than one place.

Ack.

> >- The mapgen code must be updated so that (1) it no longer assumes all
> regular
> >positions are normal and (2) it no longer assumes that the y coordinate
> >corresponds exclusively to lattitude.  It may be desirable to write map 
> >generators that are specific to specific topologies, but in general it's
> >desirable to make the current map generators generalized.
> 
> I disagree. 
> 
> The current mapgen code should be made "safe" wrt arbitrary topologies. But
> this is either by conditions on which of the generators are usable under
> which topologies, or changes to insure there are no faults when used with
> a particular topology that is deemed "safe".
> 

> The form of the current map generation (i.e. standard x-wrapped earth)
> should not be touched wrt "features" like poles, desert latitudes, etc.
> 
> If one develops new map generators for new topologies, or a more general
> form, then this should be done as a new generator. There is no reason not
> to consolidate or update internal functions where this makes sense, but
> a complete retrofit of the current system to "generalize" it is NOT the
> way to go.
> 
> Map_generators are trivial to add and make life much simpler.

This is a good idea.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Transported to a surreal landscape, a young girl kills the first woman
  she meets and then teams up with three complete strangers to kill again."
    -- TV listing for the Wizard of Oz in the Marin Independent Journal