Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2004:
[Freeciv-Dev] Re: (PR#9799) PATCH: rewrited adjust_map()
Home

[Freeciv-Dev] Re: (PR#9799) PATCH: rewrited adjust_map()

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#9799) PATCH: rewrited adjust_map()
From: "Marcelo Burda" <mburda@xxxxxxxxx>
Date: Tue, 24 Aug 2004 22:25:32 -0700
Reply-to: rt@xxxxxxxxxxx

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

Le mer 25/08/2004 à 00:39, Jason Short a écrit :
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=9799 >
> 
> I almost like the idea.
> 
> What I don't really like is the "linearize" part of adjust_map.  I don't
> like specifying 35% mountains and having the highest 35% of all tiles be
> turned into mountains.  This loses some of the texture that is created
> by the pseudo-fractal generator. 
Actual code don't do that: as until today code do a mix of mountains and
hill. this is not adjust_hmap() problem but the way of these
informations is used by make_mountains() (now make relief). this patch
change nothing of viewable map.
Has i saw you (IRC and probably before this mail) i see the relief more
linked to slope than height and put mountains all together is not my
idea,hmap is the info that has to be used to create a nice relief map (
to do).  
One important point is after this patch slope value can be estimated to
maxvalu * sqrt(number of isles)/linear_size, this allows us to write
code using slope as info, actual code some times do it, but, has slope
is unpredictable from a fractal generator to another or from a hmap
level to another, this is simply useless. this patch fix it, but not
delete any interesting info from hmap.

The linear function is all the time to be used in models, only when a
linear function fail we try some thing more complex, "gold rule of
physicist".
>  I would rather keep the clumpiness of
> the distribution of heights, and let the terrains fall out as they may.
>  Note that since the max and min values of the hmap are pretty
> arbitrary, this may not work well with the current system.  Your method
> _may_ be a sufficient approximation.
from the "gold rule", first we has to try it, if this fail to do well, i
will be the first to go back or any other way
> 
> jason
> 
Marcelo




[Prev in Thread] Current Thread [Next in Thread]