With -O2 the test works, but with -O1 the compiler complains about
missing instruction. I guess -O2 just optimizes it away in this
particular case, so the safe option is to not use it at all.
The thing is:
* Doing std::abs() and comparing to some epsilon value is crazy thing
to do with integers.
* When using unsigned integers, Clang rightfully complained that
calling std::abs() on these is a sign of insanity. This fixes it too.
Similarly as it is done in STL for C++14 literals, the user has to
explicitly put them to scope with `using` keyword to avoid accidental
collisions. If MAGNUM_BUILD_DEPRECATED is set, they are still brought to
the root namespace, but that will be removed in a future release.
Makes more sense than fully opaque black. On the other hand, creating
Color4 from Color3 or separate RGB components still sets alpha to one,
because that's the intuitive behavior.
As with Corrade, this is not exactly backwards compatible, but for
common use case without OBJECT libraries this should not be a problem.
In any case, recreate the build dir and update your copy of all
Find*.cmake modules to avoid weird things happening.
User-facing changes:
* Documentation of all Find*.cmake modules converted to
reStructuredText to follow official CMake guidelines.
* The newfangled way to use the libraries is to link to Magnum::Shaders
instead of adding ${MAGNUM_SHADERS_INCLUDE_DIRS} to include path and
linking to ${MAGNUM_SHADERS_LIBRARIES}.
* The old ${MAGNUM_*_LIBRARIES} are deprecated and now just expand to
Magnum::* target. Use the target directly. These are also enabled
only when building with MAGNUM_BUILD_DEPRECATED.
* The old ${MAGNUM_*_INCLUDE_DIRS} are removed as the Magnum::* targets
cover these too.
Internal changes:
* Global state such as include_directories() was replaced with
target-specific settings.
Doesn't solve problem I hoped it would solve (adding pointer and
Vector<1, size_t> still doesn't compile), breaks GCC 4.7 build in some
crazy way and makes certain previously-working operations (like
operator== on Vector<1, int> and int) ambiguous. Not worth pursuing
further, I think.
This reverts commit ca0892f026.
This reverts commit d6d0fd1890.
When rotation is identical, the rotation of the first dual quaternion is
returned instead, together with the linearly interpolated translation of
both (lerp of the vectors of the dual part). The additional include is
needed for `Math::lerp(Vector<3, T>, Vector<3, T>, T)`.
Signed-off-by: Squareys <Squareys@googlemail.com>
If and only if the quaternions to interpolate are equal, the angle between
them is 0.0 and we therefore cannot safely divide by the sin of that angle.
Credits to @wivlaro for finding this one.
Fixes#117.
Signed-off-by: Squareys <Squareys@googlemail.com>
Making use of sincos() for Dual numbers, constructing DualQuaternion
from dual vector and scalar parts and using
DualQuaternion::isNormalized(). Also updated the math equation to be
consistent with conventions elsewhere.
Mainly a convenience function in case you want to compute sin and cos of
the same, potentially longer expression, and you don't want to have
repeated code or temporary variables. On some architectures might use
faster instruction that computes both values in one shot.