Code outside of C4FoWRegion should not care about the internals of the
class. Therefore, we remove direct access to the backing surface (and
secondary buffer surface) and replace it instead with accessors that
return those few values that are required by outside code.
In a surprising touch, using shaders to affect pretty much every pixel
that gets drawn on screen means there is little reason for code to ask
the renderer if it knows about shaders.
There are only a couple of error values worth considering, so we can just
write out own function for it. Disable error checking in C4FoWRegion.cpp as
well, since we have the --debug-opengl flag now.
This should allow us to get rid of the GLU dependency soon.
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.
Instead, compute the projection, modelview and normal matrices explictly
and upload them as shader uniforms. This is one step towards using the
OpenGL 3 core profile.
It was almost never appropriate (played underground etc.), could not be turned off and was very repetitive. Mountain scenarios with lots of wind may activate the sound.
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.
Using memset to initialize non-POD types doesn't work. Or rather, it may
work right now, but will fail when somebody adds a member that relies on
its constructor doing something (like for example any STL container).
Either way it's undefined behavior and needs to go. Furthermore, using
it to reinitialize an object also prevents any dtors from doing their
work when needed.
A new helper function InplaceReconstruct will take an object of nothrow-
default-constructible type, and call the dtor to properly clean up
before placement-new reconstructing the object in the same location.
This is still bad design, but unfortunately removing the Default/Clear
functions from every object currently using them is a herculean task.
The problem comes from the fact that the landscape texture can be larger
than the actual landscape, and that for the last row or column of pixels
drawn at the edge of the landscape, the shader might access a texel that's
beyond the landscape boundaries, at least as part of its interpolation
when accessing a texture.
This patch fixes this by always making the landscape surface the same size
as the landscape, and then GL_CLAMP_TO_EDGE behaviour will prevent access to
pixels beyond the edge of the landscape. Modern hardware should handle
NPOT textures just fine, and they are already used in other places in Clonk.
If this becomes a problem and needs to be reverted, we could instead upload
the "real" landscape size to the shader, and clamp the texture coordinates
there to make sure to not read beyond the actually filled landscape surface.
Before, material normal bias was calculated only from a column/row of pixels right
next to the pixel in question. This sometimes led to "lines" appearing in edge cases.
The new code modified this approach to look at a whole rectangle instead, which
gives a *lot* smoother results and is only marginally more expensive.
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.
Using (0,0,0) violates normalisation assumptions, which shifts the weight
between landscape and texture normals quite massively. The new normal
code should represent a "flat" texture properly.
This gets closer to what they are representing.
More precise would be fg_mask_if_bg_is_sky and fg_mask_of_bg_is_not_sky. But fg_mask and bg_mask were terribly misleading, because sky background didn't mean the material was "in front".
* 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.
The solution is slightly hacky and not entirely stable, but for fine-
tuning this functionality is essential.
While I was at it, also reduced refresh interval so it doesn't have a
chance to lag the game.
This implements the proposal made in the forum for "shiny" materials -
material can now determine the angle at which the most light is reflected.
Shiny materials might set this lower to approximate a "reflection" effect,
and increase the "spottiness" at the same time. To compensate for the
lack of brightness without light, "emittance" can be used.
Not sure this is the most elegant way to model this - the "proper" way
here would be to have emittance, shading and specular as three separate
light parameters instead of molding one into the other and using the third
to compensate.
Furthermore, this reorganises shaders in a major way: We reduce the
number of shader files down to three, pushing a number of possible
configurations into preprocessor. I believe this should be easier to
understand, which for the moment trumps theoretical extensibility
benefits.
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.
A texture array is conceptionally what should be used in this case. One
advantage of this is that we don't have to generate mipmaps ourselves but can
let the graphics driver take care of it. Same for selection of the mipmap
level. This would even allow to choose different mipmap levels for different
textures.
This is a somewhat experimental change since it makes OpenGL 3.0 a hard
requirement for OpenClonk. I expect that this is fine, but if this causes
failures during landscape creation on common hardware/drivers we should
revisit.
Nicolas Hake