Some code here was indented like it still belonged to the loop
above, but never did, and was never intended to. This is an
excellent argument for why braces are good, especially for
statements which span more than one line.
The previous behaviour of only checking the background broke existing
maps and triggered some (performance?) bug in the mass mover. It is
still available by setting AutoScanSideOpen=2, for symmetry with
Top/BottomOpen.
Savegames with a foreground material diff but no background material
diff would not apply the foreground diff at all. As the background
material rarely changes, this broke runtime joining for most scenarios.
Consolidate the include statements scattered across the code in accordance
with the comment in C4Include.h. The advantages are listed in the same
comment.
Furthermore, it follows llvm-include-order which is the logical
extrapolation of the project's style guideline wherever possible
(C4Include.h being the most-frequent exception).
The optimizer is going to remove dead code anyway, and has the
additional advantage of doing syntax checking, so the code won't
silently break when someone changes something.
Instead of "Compiler" and "Decompiler", which make me look up what's
even going on each time I see them, use the standard terms "serializer"
and "deserializer".
Since LTCG is enabled now, we don't have to define every function inside
the headers for ~xXx super speed xXx~, which means we can strip the
headers down to their bare minimum and reduce interdependencies and
therefore recompilation times by a lot.
Otherwise, when starting the next scenario, random spots would be initially
re-lighted. That's not necessarily a problem, but unnecessary work, and it
triggered the assertion in C4FowAmbient::UpdateFromLandscape if the relight
was scheduled for a region that's outside of the landscape boundaries of the
second scenario.
None of these functions require access to any state of C4Landscape, and
they've only been used from within C4Landscape.cpp, so don't need to be
part of the header.
When clearing parts of the landscape, solid masks must be disabled
beforehand because we don't want to remove the actual solid mask itself.
Theoretically we should also temp remove solid masks before DigFree,
ShakeFree, and all of the other landscape modifiers, just in case
someone overrides the Vehicle material with stupid values.
The C++ standard library comes with perfectly fine implementations of
these functions, so there's no point in reimplementing them just for the
hell of it.
Removing solidmasks temporarily as part of the relighting procedure caused
a landscape update which modified the list of to-be-relighted regions that
is currently being iterated over. This could cause relighting of a region in
which solidmasks have not been removed, leading to vehicle pixels in the
landscape surface used by the landscape shader, which show up pink on the
screen.
Fixed this by introducing C4Landscape::_SetPix2Tmp, which changes a pixel
without causing relighting (or material count updates), and use that when
temporarily removing or putting solidmasks. This should also avoid unnecessary
computations (relighting, material count updates) when updating the landscape
or moving objects with solidmasks.
* Renamed from material shapes to textures shapes
* No per-texture, so the same material can use different shapes with different textures
* Load a shape image instead of text file with vector components
* Allow texture sizes that are not multiple of the map zoom
* Add minimum overlap parameter to draw shapes only when the given overlap is reached.
This reverts commit 8ef1f908cc. This seems to be
a performance bottleneck on some graphics cards and/or drivers. Clonkonaut
reports issues with a Radeon HD 7800.
This feature is not vital since textures can always be drawn such that they
tile properly at 512x512. While that particular problem with the Radeon card
could probably be worked around, it's just not worth it.
Nicolas Hake