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>
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.
Now works both ways. The base class works with virtually any combination
that is supported by the underlying types, so e.g. Dual<Matrix3<T>>
could be multiplied/divided with Vector3<T> (result is Vector3<T>), with
Matrix3<T> (result is Matrix3<T>) or with T (result is Matrix3<T>).
The macros, on the other hand, because they are there only to help with
implementation of *my* subclasses, restrict that to the two only cases I
need (i.e. multiplication with Dual<T> and Dual<T::Type> and nothing
else). Could be extended in the future if it needs to be.
I don't know why, but marking the output of copy constructor of any
subclass or output of conversion operator of any class as constexpr
causes MSVC to complain about non-constant expression.
Probably just another bug.
Apart from different include (<Magnum/Math/Color.h> instead of
<Magnum/Color.h>) there shouldn't be any visible change to the user. The
BasicColor3 and BasicColor4 classes are now Math::Color3 and
Math::Color4. The Color3, Color4, Color3ub and Color4ub typedefs in
Magnum namespace stayed the same.
BasicColor3 and BasicColor4 is now an alias to Math::Color3 and
Math::Color4, is marked as deprecated and will be removed in future
release. The same goes for the <Magnum/Color.h> include, which now just
includes the <Magnum/Math/Color.h> header.
Useful for squeezing out last bits of performance, e.g. in this case:
Vector3 a;
a[0] = something++;
a[1] = something++;
a[2] = something++;
In the code all elements are first zeroed out and then overwritten
later, thus it might be good to avoid the zero-initialization:
Vector3 a{Math::NoInit};
a[0] = something++;
a[1] = something++;
a[2] = something++;
This will of course be more useful in far larger data types and arrays
of these.
Previously only matrices allowed to be created either as an identity or
zero-initialized. Now all Math classes support that, including (dual)
complex numbers and quaternions.
Some classes are by default constructed zero-filled while other are set
to identity and the only way to to check this is to look into the
documentation. This changes the default constructor of all classes to
take an optional "tag" which acts as documentation about how the type is
constructed. Note that this result in no behavioral changes, just
ability to be more explicit when writing the code. Example:
// These two are equivalent
Quaternion q1;
Quaternion q2{Math::IdentityInit};
// These two are equivalent
Vector4 vec1;
Vector4 vec2{Math::ZeroInit};
Matrix4 a{Math::IdentityInit, 2}; // 2 on diagonal
Matrix4 b{Math::ZeroInit}; // all zero
This functionality was already present in some ugly form in Matrix,
Matrix3 and Matrix4 classes. It was long and ugly to write, so it is
now generalized into the new Math::IdentityInit and Math::ZeroInit tags,
the original Matrix::IdentityType, Matrix::Identity, Matrix::ZeroType
and Matrix::Zero are deprecated and will be removed in the future
release.
Math::Matrix<7, Int> m{Math::Matrix<7, Int>::Identity}; // before
Math::Matrix<7, Int> m{Math::IdentityInit}; // now
Vladimír Vondruš