[Freeciv-Dev] Re: [PATCH] Tori, rectangles and cylinders. (PR#1048)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Nov 11, 2001 at 08:36:34PM -0800, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> Gaute B Strokkenes wrote:
> > 
> > On Sun, 11 Nov 2001, hawk@xxxxxxxxxxxxxxxxxxxxxxx wrote:
> > > On Wed, Oct 31, 2001 at 08:48:35PM -0800, Gaute B Strokkenes wrote:
> > >>
> > >> Having grown tired of the discussion on this lately, I decided to
> > >> forge ahead and actually implement some of what has been discussed
> > >> lately.
> > >>
> > >> This patch does the following:
> > >>
> > >> * Add support for rectangles, cylinders (both ways) and tori to the
> > >>   various coordinate manipulation functions.
> > >>
> > >> * Add a field top of type enum topology to the civ_map struct to
> > >>   control which version is used.
> > >>
> > >> * Extend the GTK overhead view and minimap code to cope.  (I also
> > >>   eliminated all uses of map_adjust_[xy]).
> > >>
> > >> Note that map.top is unconditionally set to TOP_XCYLINDER in
> > >> map_init(), so that no incompatibilities are introduced even though
> > >> no capstring has been added or all the clients updated.
> > >
> > > Is this is a submission for inclusion?
> > 
> > Almost.  I need to finish the Xaw stuff and tighten a few loose ends
> > before it's ready to go.
> 
> AFAICT, this code will do little to help make iso-rectangular maps
> easier.  The changes to the overview code is a step in the right
> direction, but for the rest you're using "quick hacks" that won't really
> help in the general case.
> 
> Another problem is that these changes must be made to EVERY gui, which
> is one reason why I've been trying to unify some of the GUI code before
> making changes of this type.
> 
> Nonetheless, I have no direct objections.
> 
> > > Comments from other people? I have not followed the topology
> > > discussion in detail.
> 
> There are really several directions we can go with topology changes:
> 
> - Gaute's proposal would add the ability to wrap in different
> directions, without really helping the general case (i.e.
> iso-rectangular maps) much.  The up-side is that the changes are pretty
> simple.
> 
> - My idea keeps the same coordinate numbering system, but allows almost
> any topology that fits that (with certain other restrictions).  The
> changes are still pretty straightforward, but there are more of them. 
> Most notably, something like unnormalize_map_pos must be used by the GUI
> code to wrap a position into the desired set, and a number of simple
> changes are required to allow for the case where regular!=normal.  I'd
> also like to unify backend GUI code before making these changes, so that
> everything is as universal as possible.  I have a fully working "target"
> patch that I'll provide once I update it for current CVS.
> 
> - Ross's (pseudo-)proposed plan is to use different coordinate numbering
> systems for different topologies.  For instance, an isometric map would
> use "isometric coordinates".  This adds an additional layer to the whole
> thing.  We would then know that normal==regular, but we still wouldn't
> be able to use the current whole_map_iterate loops; we'd need a custom
> loop for each numbering system/topology.  This hasn't been fully fleshed
> out yet, but my feeling is that it's not much short of Reiner's
> "arbitrary graph of positions" idea, and will require a _lot_ more work
> to make all the code conform to the new conventions.
> 
> Obviously, IMO we should aim toward the second system, possibly using
> the first system as an intermediate point.  The third system is much
> more ambitious.  Of course, Gaute's and Ross's opinions probably differ.
> :-)

Ok this means that I have to go over the next version of Gaute's patch
in detail.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner