[Freeciv-Dev] Re: RFC: alternate topologies

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Tony Stuckey wrote:
> 
> On Tue, Oct 09, 2001 at 03:33:24PM -0400, Jason Dorje Short wrote:
> > Here is the proposal, in full (version 1, pretty informal).
> 
>         This is great!  Clearly worded, logically structured, and
> everything!

Thanks.  Hopefully we can refine it further.

> > 1.  Mathematical Definition of a Allowable Topology
> >
> > Any topology which fits the following informal definition should work
> > with the proposed changes.
> >
> > - Definitions:
> >   - Let Z be the set of all integers.
> 
>         Shouldn't this be "whole numbers"?
>         Why do we need negatives?  Or do we really only need -1?

I'm pretty sure we need negatives.  Many square_iterate calls go around
a given point and may be arbitrarily large; if that point is close to
the border they may wrap around significantly.  "goto" routes may travel
from (0, 0) halfway around the world to the left; these also wrap
significantly.  You might argue that you only need one map's-worth to
that side (I've seen that argument before), but I don't really think
it's an issue.

Allowing things to cover the whole plane makes things simple
mathematically and will always work.  It should be really easy, too.

Finally, it's what's currently done so it would be unsafe to change it.

> > This storage method has the advantage of easy indexing (i.e. a simple
> > map_inx()), but the disadvantage of having wasted space from
> > fragmentation.  For most topologies the wasted space should be less than
> > half of the total array; however, even so that means as much as a
> > doubling of memory consumption in these areas.
> 
>         That shouldn't be too damaging.  People playing on a 200x100 world
> are expecting significant data storage.

True.

The problem I could see if is you were playing on a 200x20
iso-rectangular world, you would only have 4000 proper map positions but
would have both map.xsize and map.ysize be about 220...leading to 48,000
map positions in the array.  This would be over 90% waste.  In a more
normal case, a 200x100 iso-rectangular map would have 20,000 proper map
positions and 90,000 positions used in the array, leading to about 75%
waste.

This problem can be put off until later by using map_pos_to_index,
map_index_to_pos, and map_index_size for all array allocations, indexes,
and unindexes.  Then the storage routines can later be changed if
desired with no change to the structures.  Or, this change can just be
made later if desired.

It's only a problem if playing on unusual maps, which isn't possible at
all now so there should be no reason to complain.

jason