Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
It should be returning twice the value, this is the half-angle. Sad that
this went unnoticed for so long, extra bad points for me to have a
complicated test but not actually verifying that the returned value
makes sense, sigh.
A *nasty* option would be to just fix it, but -- even though there's a
chance nonbody ever used it since nobody ever complained -- it would
introduce breakages to any code that fixed it and that's something to
definitely not do in a trusted codebase. So it's instead deprecated,
firing an annoying warning to whoever might have called it, and there's
a (temporary) replacement called halfAngle() that does exactly the same
but is named appropriately.
Then, once the deprecated angle() is removed (the usual deprecation
period, so a year or the span of two releases, whichever takes longer)
and enough time passes (so another year at least), I'll reintroduce it
with a correct return value.
Most of the testing scaffolding here is a preparation for the actually
complex formats like BC6/7 or ASTC. Also, it's great to be able to use
Magnum from Python to prepare data for testing the C++ Magnum APIs.
The perf cost is just too great for these to be enabled always. The only
place where the assertions are kept always is in the batch APIs -- there
it's assumed the function is called on large enough data to offset this
overhead, plus since it's often dealing with large blocks of data the
memory safety is more important than various FP drifts which were the
usual case why other assertions were firing.
The change won't make any difference in Release, but in Debug builds it
avoids calling into set() for every element. This function showed up
pretty high in profiler output for DebugTools::CompareImage, now it
doesn't anymore. In particular, for ShadersMeshVisualizerGLTest it
results in ~10% reduction in run time, which is quite significant.
The
(size - 1)/8 + 1
expression is the same as
(size - 1)/8 + 8/8
which is the same as the following in all cases except when size == 0,
for which it underflows:
(size - 1 + 8)/8 == (size + 7)/8
To avoid needless surprises, I'm changing to what's used everywhere
else, including the BitArray, and also reusing the already-calculated
value for the _data array size.
The article this API was originally based on assumes a scenario which
just *isn't* matching usual practices here, giving wrong results. Too
bad I didn't spend more time questioning the proof there and just
blindly assumed it's correct because everyone said so.
Won't be typing all that reasoning again in the commit message, see the
changelog entry and the comment in the test for details.
For generic code, which would otherwise have to invent some SFINAE
"use castInto() if the types are different and Utility::copy()
otherwise" nastiness in every such case, and that's just annoying.
Counterparts to the sRGB-converting APIs, for when one doesn't want to
perform sRGB conversion. Or for "wrong sRGB" workflows. Named like this
and not just `fromRgbInt()` to make the calls at least a bit suspicious.
I should probably go over all Math tests and include Magnum.h there. No
idea why did I do it like this back in 2010, maybe to have the Math
library "independent" from the rest of Magnum? That can be done even
without having to suffer like this...
The result of e.g. -15.0_degf is not Deg, but rather
Math::Unit<Math::Deg, Float>, and those didn't have a corresponding
TweakableParser defined. Now they do.
Funny how I didn't run into this until now.
I spent a significant amount of time reinventing the wheel, i.e.
figuring out how to use a cross product to calculate distance of a point
to a line. Only to subseqently have a breakthrough discovery of
Distance::linePoint() that actually does the same.
The distance APIs and 2D and 3D cross-products are now linked together
the math snippet is clarified, and both the 2D and 3D distance use the
same equation, saving one unnecessary vector subtraction. The
equivalence of the two equations is listed directly on that Wolfram
link.
Vladimír Vondruš