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

[jdorje@xxxxxxxxxxxxxxxxxxxxx]

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.
:-)

jason