The landscape renderer used to store texture data into the default 1D
texture, which works but is a bad idea for several reasons (and would
have broken if we had a reason to use another 1D texture anywhere else).
The GTK and OS X platforms already ignored the requested bit depth and
always used 32 bit. Windows and SDL would set a 16 bit color depth for
the screen, but still did all of the rendering short of the final
present in 32 bit.
The former is not available in a OpenGL 3 core profile, but glGenerateMipmap
is available since OpenGL 3.0, and so is always available when we have a
core profile.
This reverts commit 790219ac7e.
This commit broke support for Mac OS X since Apple only supports OpenGL 3.0
with a core profile, not a compatibility profile. Revert this commit
temporarily for the 7.0 release, until we port all OpenGL usage to the core
profile with 8.0.
This fixes#1495.
Replace the hardcoded VAI_ constants with that. The VAI constants are now
moved to C4DrawGL as C4SSA_ constants, similar to the C4SSU ones. This allows
to introduce other attributes to replace vertex positions, normals, colors
and texture coordinates with attributes in later commits. This, in turn, is
needed because the built-in attributes are no longer available in the OpenGL
core profile.
Also, while at it, cleanup C4Shader a bit. Use std::vector<> instead of
maintaining an own array of uniform names. Delete the vertex and fragment
objects after the full shader program has been linked. Make sure that
C4Shader::Init keeps the old program in place if the new one cannot be
compiled or linked.
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.
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.
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.
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.
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.
In comparison to the old system, this is a downgrade - instead of being
able to set a full color mapping by gamma ramp, we now get just a value
per colour channel.
Upside is that we do not need to play around with the global gamma ramps
any more, which was arguably the wrong way to do it.
This commit will likely break everything that has been using gamma so far.
This should improve cache coherency by having all surface tiles adjacent
instead of strewn across the heap. This will also remove an indirection
in the common case of only using one tile.
With this change, an additional rectangle is stored in C4FoWRegion that
represents the area covered by the viewport in fractional floating point
coordinates. This allows the light texture to be created for an arbitrary
portion of the landscape, and the coordinate transformations for the
shaders will still work.
Also, since the additional rectangle uses floating point precision, the
computed coordinate transformations do now give the exact same result as for
the landscape pixel-by-pixel, and there should not be any offsets left.
I also hope that this change improves or fixes the single-pixel-lines of sky
that are sometimes seen at the edges of the viewport.
This allows to see the whole landscape without any areas covered by FoW
in the global viewport. Basically the ambient lighting is set to 1.0
independent of the ambient light map. In the course of this, a second
shader for the landscape has been introduced.
There were two problems with the previous transforms:
1) For inverting the Y axis for the ambient map, the total height of the
output window is needed, not only the viewport region.
2) The Y offset to only use the part of the light texture that is being
rendered to was not applied.
In order to keep the transformations more readable, a new lightweight class
C4FragTransform has been introduced which can only handle translations
and scales in x and y.
Julius Michaelis