Followup to previous commit -- links to opengl.org are now redirected to
khronos.org and the extension links have the same format for both GL and
GLES. That allows me to remove some of the Doxygen aliases and use just
a single set of the functions for both GL and GLES.
On Windows NVidia drivers the glTransformFeedbackVaryings() does not
make a copy of its char* arguments so it fails at link time when the
original char arrays are not in scope anymore. Enabling *synchronous*
debug output circumvents this bug. Can be triggered by running
TransformFeedbackGLTest with GL_KHR_debug extension disabled.
The previous AbstractShaderProgram::setUniform(Int, UnsignedInt, T*)
function is now alias to the new one, is marked as deprecated and will
be removed in some future release.
Full support for EXT_transform_feedback, transform feedback objects
from ARB_transform_feedback2 and equivalent OpenGL ES 3.0 functionality.
Example usage is in src/Magnum/Test/TransformFeedbackGLTest.cpp, I'll
add some example later.
No backward compatibility issues should exist, as the class is in most
(if not all) cases used with unscoped name:
class MyShader: public AbstractShaderProgram {
public:
typedef Attribute<0, Vector3> Position;
// ...
};
According to reports on delphigl.de this extension is far more supported
in comparison to the NV version (and also there's much less FF cruft in
the specification).
In nearly every case the attributes are bound and uniform locations
queried with constant char arrays:
bindAttributeLocation("position", Position::Location);
colorUniform = uniformLocation("color");
Avoiding conversion to std::string and passing const char(&)[size]
directly will avoid needless allocation (and later deallocation) for
every call.
In most cases the label is set directly from code, e.g.:
texture.setLabel("diffuse-duck");
Avoiding conversion to std::string and passing char(&)[size] directly
will avoid one allocation and deallocation. Better solution would be to
use std::string_view everywhere, but we're not in C++17 yet.
Convenience overload to attachShader(), allowing the user to specify
more than one shader at once. Just a complement to initializer-list
versions of compile() and link(), but without any performance
difference.
It makes sense, but this ordering also helps to avoid bug in Doxygen
1.8.6+ which merges next non-xrefitem section with the previous one (so
e.g. the TODO list contained the following @see block, which is not
desired).
Until now the textures were bound to layers, which was rather confusing,
especially when binding layered textures to layers (gaah). Also the
wording might have implied that each texture must be in some layer in
order to make it usable in shader. This is no longer the case with (yet
unimplemented) bindless texture, so another reason to remove the
confusion.
All occurences of texture layers were replaced texture binding units to
follow OpenGL naming. It was mostly in the docs, except for
already-deprecated *Layer enums in shaders, but they will be removed
soon anyway.
As g_truc said long ago:
https://twitter.com/g_truc/status/352778836657700866
Currently there is not much use of this as the stock shaders are
compiled one by one (and doing it differently would make things
needlessly overcomplicated), but the users can do parallel compilation
of their own shaders.
Also removed a bunch of now-unneeded TODOs and made the linker/compiler
code nearly similar. Also the whole Shader::compile() call now does two
allocations in total instead of two allocations for each shader.
In all other places (e.g. Math, SceneGraph), SomeClass<T>::Type is
always T. I spent twenty minutes figuring out what went wrong, so better
have this consistent.
Also update the test to check for these, as they apparently were tested
only indirectly through the MeshGLTest.