[Freeciv-Dev] Re: RFC: 8-topology system

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Raimar Falke wrote:
> 
> On Tue, Oct 16, 2001 at 06:22:35PM -0400, Jason Dorje Short wrote:
> > Raimar Falke wrote:
> > >
> > > On Tue, Oct 16, 2001 at 01:42:48PM -0400, Jason Dorje Short wrote:
> > > > Here is a (hopefully) full explanation of how I propose to implement an
> > > > 8-topology system.  The eight topologies include flat vs isometric,
> > > > north-south wrapping vs no wrapping, and east-west wrapping vs no
> > > > wrapping.  We also allow the possibility of adding non-rectangular maps
> > > > in the future.  Any of these 8 topologies will work under my proposed
> > > > general topological system (an earlier post), either with or without the
> > > > linear-combination-of-vectors (LCOV) extension (LCOV allows
> > > > wrap_map_pos()).
> > > >
> > > > The current code defines only map.xsize and map.ysize (henceforth
> > > > referred to as xsize and ysize).  These currently define the topology
> > > > itself.  Under the new system, they will only define the bounding
> > > > rectangle for the topology.  The topology itself will be referred to by
> > > > another set of values (declared either within the map structure or as
> > > > part of a separate topology structure):
> > > >
> > > > - shape: 0 for rectangle; no other valid values yet.
> > >
> > > 1 for a ellipse
> > >
> > > I think that another shape is good. This may be of no real use but it
> > > allows use to test the code. And a non-isometric ellipse has the
> > > semantics of most north <=> y=0. Also such an ellipse will also have
> > > non-real tiles in the rectangular xsize*ysize.

> > > For testing such shape may also omit wrapping.
> >
> > Omit wrapping?  How could such a shape possibly wrap?

...
 
> You may go from A to B and from C to D.

Ugh.  I'd say the server should refuse to wrap this shape.  It is better
than a flat rectangle, IMO.

> > We have (width, height) as the width and height of the ellipse.
> > xsize==width and ysize==height.
> >
> > The center point is (width/2, height/2).
> >
> > Allow the ellipse to range as far out as possible before encountering
> > the next row.  For instance your picture above would become something
> > like

...

> > This preserves the ellipse while making the ends as unpointy as
> > possible.  It means that the horizontal and vertical radiuses become one
> > larger ( (width/2+1) and (height/2+1) ) but we want to use <
> > (inequality) rather than <= in our comparison.
> 
> This figure was done with:
> ------
> a=13
> b=9
> 
> for y in range(-10,11):
>     for x in range(-15,16):
>         if x*x*b*b+a*a*y*y<=a*a*b*b:
>             print "#",
>         else:
>             print " ",
>     print

OK.

If we add any shape, though, it must be very clearly defined so that
every freeciv everywhere interprets it the same.  Thus, I propose my
definition instead of yours (for the reasons above).

> > The equation then becomes
> >
> > Let
> >   xr=widtht/2
> >   yr=height/2
> > in
> >   ( (x-xr)/(xr+1) )^2 + ( (y-yr)/(yr+1) )^2 < 1
> >
> > Which can either be done floating-point, or multiplied out to get a
> > very-long-but-integer-only equation.
> 
> These are details. So can we add this shape to the 8 still virtual
> forms of a map?!

Yes, of course.  I didn't think that part was in question :-).

But, there are several steps here that have been wrapped into one RFC. 
The first thing to consider is whether the topology information (shape,
isometric, width, height, ns_wrap, ew_wrap) will be sufficient.  A
hexagon, for instance, could have up to 3 directions of wrapping.

Then, the details of each possible shape must be finalized.

How would you do an isometric ellipse? :-)

jason