[Freeciv-Dev] Re: (PR#7287) Extended Topologies

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >

Marcelo Burda wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
> 
> Le jeu 19/02/2004 à 22:48, Jason Short a écrit :
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
> 
> 
>>Next, I'm not happy with the xsize/ysize/size/ratio setup.  If you
>>change the xsize nothing happens, and you can't figure out why.  At a
>>minimum the user needs an error message here.  (This is also something
>>that should be its own patch.  I'm not convinced that we need this.)
> 
> me too
> i thinck the best is no more set xsize and ysize directly but only 
> ratio and size.
> this way init_topo make maps whit desired ratio and size but make good
> xsize and ysize for all topologies, some topo need even numer on
> [xy]size and some times ysize need to be ysize % 4 == 0.
> this is the work of init_topo and set_ratio in map.c

That sounds okay to me.  But the granularity of the 'size' variable 
needs to be smaller.  Also we must be careful not to have values too 
high (map positions < 255).

>>The topology_id isn't fully explained (in "help topology").  What are
>>topologies 5-15?  Why don't we have 22-31?
> 
> the problems is you kep ISO-map option in topology_id, iso-map need to
> be a separate option an not a bit flags of topology_id.
> for me topology_id is a list of selected topologies, first the
> cartographicals ones(flat, cylinder,quincuntial) then some ScFi(exotics)
> ones Torus,Mobius, etc.
> but the ISO_FLAG break it

It's just another bit; it shouldn't break anything.  Just make sure you 
use appropriate masks.  We may later add a HEX_FLAG for hexagonal tiles. 
- this will probably go into the same bitfield.

I'm not opposed to making these all separate values, but we decided 
before not to do it that way.

>>I'd like to set up the topology_id as a combination of bitfields:
>>
>>Xwrap: 2 bits, 4 values:
>>Ywrap: 2 bits, 4 values:
>>  NONE, SIMPLEST, MOBIUS, REVERSED
>>iso: 1 bit
>>
>>This is similar to what you have (I think), but the bit order is different.
>>
> 
> this is problematic, this make a big number of topo where some are
> uniteresting.
> 
> MOBIUS is maked as offset wraps combined to simplest wraps
> but all others topos maked with offset wraps are realy bads!

You misunderstand what a mobius wrap is.

It's not

+c-defabc-d
+| |||||| |
+f-ABCDEF-a
+l-GHIJKL-g
+r-MNOPQR-m
+g-STUVWX-s
+| |||||| |
+u-vwxstu-v

as you have it in your documentation.  This is an interesting wrapping 
(probably better than a donut for a sphere approximation).  But an 
offset wrapping may only be combined with simple wrapping or no wrapping 
(I think), and no wrapping would be really bad.

A mobius wrap is where you reverse the direction of the map.

   x-ABCDEF-s
   r-GHIJKL-m
   l-MNOPQR-g
   f-STUVWX-a

so it may be combined with any other form of wrapping in the other 
direction (I think).  Whether this would give you a fun map or not is 
another question.

> REVERSE-SIMPLEST SIMPLEST-REVERSED and REVERSED-REVERSED WRAPS
> combinings are QUINCUNTIAL TOPOS, we only need one of this not 3! 

So which one is it to be?  reversed-reversed gives a better projection 
for the sphere, but simplest-reversed gives you just 2 singularities 
(which can be hidden at the poles).

> NONE-SIMPLEST and SIMPLEST-NONE are the classical and the uranus( a
> classica one too rotated 90°)

Yep.  I'm guessing nobody will ever want uranus, but I don't know.

> and more and more
> 
> it this best to limit the list to a selected set of topos.

Are you sure?  Who chooses what to limit it to?  And why shouldn't 
people be able to use other topologies if the code can handle them, 
simply because there's no topology ID for them?


> make a clima_function for generators to all 32 way to combine are a hard
> work for only 6 reals topos!!

Maybe.  But I would hope that the different flags would combine 
linearly, not exponentially, so we'd only really have about 5 cases.

>>Finally, examples.  The biggest problem we have is convincing people
>>that we should provide these topologies.  The biggest selling point will
>>probably be the quincunx topologies, which make a good approximation of
>>a sphere.  But I can't figure out how to turn your earth scenario into a
>>quincuncial earth,
> 
> the scenario need only good wraps to work fine as quincuntial. 
> 
>> since I don't know what the topology values are.
> 
> i not undestand you!
> 
> if you like play it for see you need instal Extended Topologie Patch And
> Quincuntial patch in a litle old cvs version (patch no more compile in
> the latest)
> from a 21-jan-cvs
> patch first ExtendedTopologies.V2.01.diff from (#7287)
> then patch ExtendedTopologies.V3.01.diff from (#6721)
> and you can play the scenario(#7295) with quincutial topo with -t
> trident

I used the ExtendedTopologies but not quincuncial patch.

---

Anyway, I suggest we start simple.  Take a simple feature or cleanup 
from your patches (map_clima or city_map_iterate_known) and provide a 
patch that just does that.

jason