Previously, on a straight line of a one corner up slope with the adjacent
steep sloop the Z would increase one step every two sub pixels, except for one
case where one sub pixel is skipped. Similarly, a steep slope with two
adjacent one corner up slopes, would have a bump in the height line along the
diagonal whenever it enters/leaves the steep slope tile.
Previously it checked the position in non-driving direction to "guess" whether
a ground vehicle was using the function, so on tunnels/bridges it could either
return the Z of the (virtual) ground compared to the Z of the path the vehicle
would take.
Terraforming through objects placed on water didn't properly remove docking tiles as expected.
By moving some logic regarding removal of docking tiles into DoClearSquare, the issue is solved, while also simplifying code, avoiding repetition elsewhere.
This is using a non-intrusive type-traits like templated system, which
allows compile-time validation that the command table and the command
enum match up.
This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.
Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.
Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.
This is an indication value; the game tries to get as close as it
can, but due to the complex tropic rules, that is unlikely to be
exact.
In the end, it picks a height-level to base the desert/tropic
line on. This is strictly seen not needed, as we can convert any
tile to either. But it is the simplest way to get started with
this without redoing all related functions.
Setting the snow coverage (in % of the map) makes a lot more sense
to the human, while still allowing the niche player to set (by
finding the correct %) a snow line height they like. This makes for
easier defaults, as it decoupled terrain height from amount of snow.
Maps can never be 100% snow, as we do not have sprites for coastal
tiles.
Internally, this calculates the best snow line height to approach
this coverage as close as possible.
Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.
This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.
It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).
Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.
This means that for NE/NW, it should have one more in case of
freeform-edges, and in case of SE/SW it should have one less.
Reminder: freeform-edges only adds VOID tiles on X=0 and Y=0.
Peter Nelson