* Optimize packet construction functions
Some of the functions that construct packets in
connection.cpp are using a const reference to get the raw
packet data to package and others use a value passed
parameter to do that. The ones that use the value passed
parameter suffer from performance hit as the rather bulky
packet data gets a temporary copy when the parameter is
passed before it lands at its final destination inside the
newly constructed packet. The unnecessary temporary copy
hurts quite badly as the underlying class (SharedBuffer)
actually allocates the space for the data in the heap.
Fix the performance hit by converting all of these value
passed parameters to const references. I believe that this
is what the author of the relevant code actually intended
to do as there is a couple of packet construction helper
functions that already use a const reference to get the
raw data.
* Optimize packet sender thread class
Most of the data sending methods of the packet sender thread
class use a value passed parameter for the packet data to be
sent. This causes the rather bulky data to be allocated on
the heap and copied, slowing the packet sending down. Convert
these parameters to const references to avoid the performance
hit.
* Optimize packet receiver thread class
The packet receiver and processor thread class has many
methods (mostly packet handlers) that receive the packed data
by value. This causes a performance hit that is actually
worse than the one caused by the packet sender methods
because the packet is first handed to the processPacket
method which looks at the packet type stored in the header
and then delegates the actual handling to one of the
handlers. Both, processPacket and all the handlers get the
packet data by value, leading to at least two unnecessary
copies of the data (with malloc and all the slow bells and
whistles of bulky classes).
As there already is a few methods that use a const reference
parameter for the packet data, convert all this value passed
packets to const references.
6125 is the time of first full light according to 'get_node_light()',
and the time of first full light visually when basic shaders are on.
This is the optimum default new world start time, taking all possible
games into account.
The previous time assumed a game similar to Minetest Game. Games
should set this setting themselves according to their needs.
It turns out there is no need to return the new value and
preserve the old one in random_turn, the procedure can be
made to modify the value in-place. This saves quite a bunch
of parameter and return value copying.
Previously, when basic shaders were enabled, the function
time_to_daynight_ratio() returned values jumping between 149 and 150
between times 4375 and 4625, and values jumping between 999 and 1000
between times 6125 and 6375, (and the corresponding times at sunset)
due to tiny float errors in the interpolation code.
This caused the light level returned by blend_light() to jump between
14 and 15, which became noticeable recently as those light levels were
given different visual brightnesses.
Add early returns to avoid the problematic interpolation, and to
avoid unnecessary running of the loop.
Makes the liquid waving shader per-nodedef like waving leaves/plants,
instead of being applied to all liquids.
Like the waving leaves/plants shaders, the liquid waving shader can
also be applied to meshes and nodeboxes.
Derived from a PR by t0ny2.
Like randomwalk caves, preserve nodes that have 'is_ground_content = false',
to avoid dungeons that generate out beyond the edge of a mapchunk destroying
nodes added by mods in 'register_on_generated()'.
Issue discovered by, and original PR by, argyle77.
This change permits to use up-to-date compilers, clang-tidy and
clang-format
It also refactor the tidy/format step to drop the binary selection from
scripts and perform it directly in travis
Shorter, simpler, clearer and more consistent with other mapgens,
while preserving functionality.
Base terrain shape is unchanged.
With the 'vary river depth' option disabled, river surface level
is unchanged.
Behaviour of the 4 heat/humidity/river depth options is very
slightly changed due to bugfixes and code cleanup (the mapgen is
'unstable').
Apply heat and humidity gradients above water_level instead of
above y = 0.