- Use explicit conversion to `T`
- Use `std::` for `acos, cos, sin` to avoid use of double only functions
- Do not mutate variables in math code to avoid confusion
Signed-off-by: Squareys <Squareys@googlemail.com>
Should help people understand the code and counteracts the unreadability
caused by the optimization commit at least a bit.
Signed-off-by: Squareys <Squareys@googlemail.com>
Optimized with simple code tricks, some very complex math (like `2*0.5=1`),
and principal of locality. Things the compiler would probably do for me
anyway. Was able to remove about 6 useless float multiplications.
Signed-off-by: Squareys <Squareys@googlemail.com>
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.
It worked flawlessly when crosscompiled from Linux, but compiling that
natively causes the linker to loudly complain about undefined references
to ConfigurationValue structs. I think it worked well under 4.9.2 (but
that mess had a slew of other ugly problems, such as complete inability
to produce non-crashing C++11 code under x64). The linker error is
caused only because I tried to reduce binary bloat, so I'm just
disabling that for MinGW and screw that. No problem under MSVC.
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.
It should generate the same (constexpr) code, but this way it doesn't
go through replicating the zero value four times and just
zero-initializes the data array in vector. Also fixes "not a constexpr"
issues with GCC 4.6 in compatibility branch (but these shouldn't be
there anyway).
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.