[Freeciv-Dev] Re: (PR#8632) Easy way to set map size with auto ratios (seteables if desired)

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

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


Gregory Berkolaiko wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> 
> On Thu, 3 Jun 2004, Jason Short wrote:
> 
> 
>>  X X X X
>>   X X X X
>>  X X X X
>>   X X X X
> 
> 
> This is a very good example.  Normally you'd expect h-size to be the
> number of times you have to press "right" button to get from the left edge
> to the right edge.  Similarly the v-size.  And in the example above it's
> 4x2, but as Jason points out the example has 16 tiles!
> 
> So we do have a problem.  And ratios is not a bad way to go about it.

Actually it is 4 x 4, and follows the native coordinate track since the 
mechanics of (adjacent) movement have one jog up the NS direction (look at 
various documents and coordinate descriptions for hex and iso).

Your insight that the number of presses is probably a good way to figure out 
how the user views this is quite good. Use it for GUI input dialogs, but do 
not change the underlying native code core mechanics for how this is managed 
  to develop incremental topologies.

GUI and presentation ideas have little benefit for core storage concerns and 
some of the topologies will *never* fit into any systematic presentation, 
though they can always be defined to have native coordinates that are a best 
mix of storage efficiencies with some concern for viewing in a rectangular 
GUI window (often useful for debugging dumps/views).

> However, I would go for a single variable size, letting the server figure
> out the actual parameters depending on the topology and the aestetics of
> the coder.  Five predefined sizes would be enough, can have names/aliases
> like tiny, small, compact, midsize, big and huge ;)

Again, this is fine for the naive user presentation level, but not the 
underlying core mechanics. The advanced user presentation tab should be able 
to get right down to xsize,ysize dimensions and set them within topology 
rules (e.g. even or odd wrapping constraints).

And since the defaults at the naive level are predefined, there is no need 
for size and ratio concepts to percolate to any other code, just a default 
map and a bigger/smaller control in the GUI dialog is all that is needed.

> If someone has nothing better to do and _really_ wants to set the sizes by
> hand they can edit the source.
> 
> G.
> 
> 
>>This map is 8x4 if measured in "natural" coordinates (4x2 is also a
>>reasonable description).  But there are 16 tiles on this map.  So you
>>can't have it both ways.  Either size or aspect must be wrong if you use
>>integer values.
> 
> 
> 
> 
>>The above map is 4x4 in native coordinates.  This is the method
>>currently used.  It is like the 8x4 natural system but compressed 2x in
>>the X direction.
>>
>>-----
>>
>>It would be possible to have "scaled natural coordinates" that are like
>>natural coordinates but scaled to have the correct size.  The problem
>>with these is that they're irrational, so you have to round off and you
>>end up with small rounding errors.  In these terms the above map would
>>be a (4S, 2S) map where S = sqrt(2).  So the user would set the map up
>>as (5,3) (aiming for 15 tiles) but (after one value is multiplied by S
>>and the other is divided, and both are rounded) would end up with a map
>>whose native dimensions are 4x4 (16 tiles, 2:1 ratio).
>>
>>Another example is the 80x50 map.  This is translated to a 57x71
>>"native" map which has about an 8.03:5 ratio and 4047 total tiles.
>>
>>Is this method better?
>>
>>-----
>>
>>Note that every other civilization game (AFAIK) uses a one-dimensional
>>size value rather than providing xsize, ysize values.  I don't remember
>>anyone ever complaining about this being too simplistic.
>>
>>jason
> 
> 
> 
> 
>