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.
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.
The GLEW headers of Ubuntu 12.04 LTS don't know about GL_KHR_debug yet,
so we have to test for it before using its enum. Additionally, drivers
without support for GL_KHR_debug would emit INVALID_ENUM, so we test for
driver support too.
When an error's log output is represented graphically the graphics
operation can lead to another error (or the same error again), which
will be logged graphically again and so forth, until stack overflow.
So log to the log file only.
4x3 matrices use the same number of uniform components as 4x4 ones.
If we're short on uniform components, don't transpose the transformation
matrix before sending it to the shader, and transpose it in the shader
itself instead, saving 4 components per bone.
Instead of transforming all vertices on the CPU every time an animation
progresses, we now only recalculate the skeleton, leaving the heavy
lifting for the GPU. This also means we no longer have to push all
vertices onto the bus every frame, because the mesh isn't changing and
can therefore be stored in a GL_STATIC_DRAW VBO when it's first loaded.
The downside of this approach is that there's only a limited number of
uniforms and vertex attributes we can pass to the shader. At the moment
these limits are a maximum of 128 bones per skeleton, and no vertex can
be influenced by more than 8 bones at once. So far this is no problem,
as the most complex skeleton in the base game uses less than 64 bones
and no more than 6 bone weights per vertex.
glGetString(GL_EXTENSIONS) is deprecated starting with OpenGL 3.0.
Instead, you're now supposed to retrieve the list of extensions one by
one with glGetStringi.
We've been using OpenGL 2.1 features for some time now, and hardware has
started supporting OpenGL 2.1 in 2005. I doubt this will make anyone
unable to run the game, and it's certainly better than crashing because
of a nullpointer dereference when some GL function we use can't be
found.
Depending on how current your headers are, the userParam parameter to
GLDEBUGPROCARB may be const, or it may not. The ARB has added the const
qualifier at some point after publishing the specs. Hooray for breaking
API changes.
This introduces a new command line parameter "--debug-opengl", which
will create special debug OpenGL contexts and attach a callback that the
driver will invoke when it detects a problem. The callback will then
write the error message to the logfile, and break into the debugger if
one is attached.
Currently only works on Windows.
gluErrorString returns latin-1 encoded strings. Our code expects to
receive UTF-8 encoded strings everywhere, so make sure that the strings
are converted before passing them on.
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.
This will allow to avoid some code duplication when computing the coordinate
transform from fragment coordinates to ambient and light texture coordinates.
This introduces a new texture, an ambient light map, that is generated
automatically at the beginning of the round by the sky portion of the
landscape. This basically makes everything that is close to sky visible
by default.
The shaders have been adapted so that they deploy direction-independent
lighting for the ambient component, and the current (diffuse) behaviour
for the diffuse component. This makes the shaders use an additional
texture unit that represents the ambient light. We can think about merging
this information into the light texture, but the coordinate systems are
different at the moment, so this could be performed at the stage of light
texture generation.
For meshes, the ambient material is not actually used, but instead a
diffuse light from the front is used. This makes many meshes look more
interesting, maybe also because the ambient material setting of most
meshes are not set correctly at the moment.
This code is only used for the low-resolution landscape that is hardly in use
anymore. The code was mostly a duplicate of the standard C4Surface blit
function, CStdGL::PerformBlt, with some added code for blitting material
textures with higher resolution. However, that code was not enabled anymore
by the classic landscape renderer either, so it seems safe to remove it.
The landscape is now simply drawn by C4Draw::Blit.
The support is not yet fully implemented; there are some transformations
missing. However, since the FoW support at the moment seems to be broken
(#1168) this feature cannot be tested properly.
Peter Wortmann