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.
Why did I do this:
* It is more clean, shorter and nice looking with method chaining,
i.e. instead of:
shader.setColor(...)
.setOtherParam(5);
texture1.bind(MyShader::Texture1Layer);
texture2.bind(MyShader::Texture2Layer);
We now have this:
shader.setColor(...)
.setOtherParam(5)
.setTexture1(texture1)
.setTexture2(texture2);
* It is now also clear which texture type is expected, the layer
constant did not say anything about type.
* Also it is possible to use new features (multi bind, bindless
textures etc.) while preserving the same public API.
The only potential disadvantage is that the textures don't stay bound
like uniform values do, but this become a non-issue with bindless
textures. As usual, the old way is now deprecated and will be removed in
some future release.
Previously the API didn't encourage the user to set up and activate
shader before drawing the meshes, leading to unintuitive behavior:
// Can I just call draw() or do I have to fully understand the
// meaning of the universe before?
mesh.draw();
Now the draw() needs the shader passed explicitly as parameter, which
should hint that the shader must be set up somehow:
// Right, so this needs just a shader and that's all. Expecting this
// I fortunately *did* configure all the uniforms before this call.
mesh.draw(shader);
It is also possible to pass the shader as rvalue, in case the drawing is
just a one-off thing and is already fully configured.
mesh.draw(MyShader{});
As usual, the original API is kept, is marked as deprecated and will be
removed in some future release.
Also added (currently disabled) ES implementation (provided by
EXT_separate_shader_objects). Unfortunately it's not possible to reduce
the function count, because ARB_separate_shader_objects and
EXT_direct_state_access are completely independent. Also double uniforms
are supported since GL 4.0 and SSO are since 4.1, so we can't omit
old glUniform*() calls for doubles either.
As we are now using absolute includes, there is no need to prefix
everything with "magnum<Namespace>" etc. All generated configuration
files are renamed to configure.h and their path is included _before_
everything else to avoid accidental collisions.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Makes it possible to properly compute offset when adding matrix
attributes to mesh. The matrix-related test cases in Mesh test are now
passing. The vector count is now enum value to make it more clear that
that is compile-time constant independent of what was said in
constructor.
Can't test EXT_debug_label, as that is apparently OSX 10.9-only. Added
GL tests for all implemented objects. KHR_debug is selected first, if
that is not available, fall back to EXT_debug_label. If neither is
available, the functions are no-op.
I hope EXT_debug_label gets replaced by KHR_debug later, thus it is now
only "emulated" through KHR_debug enums.
Renamed AbstractShaderProgram::maxSupportedVertexAttributeCount() to
maxVertexAttributes(), the old function is now an alias to retain
source compatibility, will be removed in future release.
Also printing the values in magnum-info.
In 1.8.5 it is now possible to reference directly to enum member.
Hooray! Also added explicit @ref here and there, fixing some referencing
bugs along the way.
Vladimír Vondruš