Basically add another layer of indirection around accessing VAOs. The problem
is that VAOs are not shared between OpenGL contexts. This mechanism allows to
treat them mostly as if they were shared if they are only accessed through
the API defined in CStdGL.
This is accomplished by caching all existing VAOs per context. If a VAO is
being accessed, it is checked whether that VAO exists in the currently
selected context. If yes, return it, otherwise create a new VAO and return it,
together with a flag that indicates that the VAO needs to be initialized.
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.
Some sort of smooth scroll information was passed down to the engine which
didn't handle it properly, or the units with which they were reported to us
were different from what the engine expected. For now, just use fixed scroll
offsets until we implement proper delta-y-aware scrolling in C4MouseControl.
The fix for #1574 might have also helped with this in recognizing when Control
is pressed and when it isn't.
For example, keydown events when pressing/releasing the shift, alt, or control
keys. With this version this is needed ingame e.g. to pick up objects with
Shift.
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.
I don't expect much of a performance benefit from this, but it works toward
removal of legacy OpenGL usage. Note that we are already using VBOs for
meshes, so this does not require any functionality that we don't require
already.
The DynamiteBox sets the PictureTransformation to a degenerate matrix, to
prevent it from being rendered. Exit early in this case, since we are not
going to render anything anyway, and avoid the assertion when inverting the
matrix.
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.
Surfaces are initially created in locked state, and only when unlocked the
memory buffer with the surface data is uploaded to the GPU. The FoW code
however never unlocks the surface but instead operates on the OpenGL texture
directly. To fix this, introduce a new flag for C4Surface to create it in an
unlocked state.
This is not a memory leak in the traditional sense as a pointer to the buffer
is still available and is being freed when the surface is being destructed
at the end of the game. However, during the game there might be several
megabytes allocated that are never used.
I'm not really sold by this Lock/Unlock mechanism. Instead, there should
simply be a function to obtain the current texture data, and a function to
upload new texture data. That's for another time though...
For some reason, the C4TexRef constructor first uploaded a set of nulled
texture data, just to be replaced by the actual image data when Unlock()
is called. Skip the unnecessary step and instead just reserve the video
memory in the constructor.
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 the game initialization code, we're setting the thread locale to the
user's default locale. This is bad when generating shader code because
it may lead to floats being written with commas instead of dots for the
decimal separator, which in turn confuses the GLSL compiler (because it
parses the comma as the comma operator). So now we just temporarily set
the C locale while generating shader 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.
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.
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 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.
It looks like sometimes graphics drivers don't report the correct number for
maximum uniforms, since the workaround was enabled even though Newton
confirmed disabling the workaround worked just fine on his GPU. Therefore,
don't listen to what the graphics driver is saying but just try to compile the
shader, and fall back to the workaround if the compilation fails.
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.
* There was an off-by-one-error causing a blank line at the screen upper screen border.
* Remove ApplyGamma. It is always applied because Gamma is just part of the drawing shaders now.
* Save by copying rows instead of pixels for whole map screenshots.
Armin Burgmeier