With ARB_multi_bind it is needed to associate the texture with some
target before calling glBindTextures(), otherwise the texture is
treated as invalid.
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.
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.
The previous way was half-working at best, as it handled array textures
improperly. Now there is overload for each texture type. The old way
with attachTexture*D() is marked as deprecated and will be removed in
future release.
Each texture has slightly different usage requirements and having
everything under one generic class is not worth the additional runtime
checks and whatnot. The current way with Texture::Target enum
(hopefully not too widely used) is now deprecated and will be removed in
some future release. However general Texture1D/2D/3D usage is not
changed in any way.
This smells fishy. The function _does have_ a no-op fallback
implementation to remove the need to wrap everything with an #ifdef
and/or extension check, so why I did exactly that everywhere?
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.
Vladimír Vondruš