I'm not exactly sure where was the actual problem, but it seems to
be related to definition of templated function with static member
variables in header file in combination with dynamic libraries, causing
multiple definitions of a symbol which did or did not lead to compile
error and/or things breaking in horribly unpredictable way.
Previously it was done via (undocumented) macros, depending on include
order, which is great until it breaks horribly after random unrelated
changes. Currently it is done via black template magic and I'm
still afraid of including it in the public documentation.
There should be no visible change to the end user except for possibly
one less randomly weird bug (#79? couldn't reproduce).
... well, looking at the diff, the solution is still an ugly **********,
but at least it seems to work.
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.
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.
Borrowed from libstdc++'s std::unique_ptr implementation, on GCC it
generates somehow different error than expected (complains about invalid
application of sizeof() where it should (or not?) print the
static_assert message.
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.
It adds much more convenience. Only some resources can't be moved around
(i.e. those with someone pointing at them), which isn't excuse for
forbidding copy/move altogether.
Finally it is possible to do convenient things like this again:
DebugTools::ResourceManager::instance()->set("red",
DebugTools::ShapeRendererOptions().setColor({1.0f, 0.0f, 0.0f}));
Passing pointer as function parameter will now mean that it is possible
to pass `nullptr`. Some code examples now look like the parameter is
copied instead of referenced, which is misleading. Updated the
documentation to reflect that more clearly.
Makes some cases less consistent (and some convenience shortcuts
impossible), but goes well with the attitude "don't use pointer when it
can't be null".
Assumes that no resources of given type are referenced. The test case
for this is awful, as I can't think of a way to test which would work
without trying to decrement reference counter on already deleted
resource. Added just-to-be-sure assertion to make it fail early and not
somewhere deep in STL.
Previously was done per type (i.e. for each type delete loader and then
the data), wasn't usable when the loader stored different resource type
(which is the only case where it is useful).
Vladimír Vondruš