Also updated all dependent classes to follow the change, such as Color
and Rectangle. Backwards compatibility for GCC 4.6 (with lack of support
for delegating constructors) will be done as non-constexpr constructor
using operator=().
Overall architecture is simplififed with this change and also it's not
needed to use reinterpret_cast in matrix internals anymore, thus there
is no need for operator() and [][] works now always as expected without
any risk of GCC misoptimizations.
On the other side, constructing matrix from list of elements is not
possible anymore. You have to specify the elements as list of
column vectors, which might be less convenient to write, but it helps to
distinguish what is column and what is row:
Matrix<2, int> a(1, 2, // before
3, 4);
Matrix<2, int> a(Vector<2, int>(1, 2), // now
Vector<2, int>(3, 4));
For some matrix specializations (i.e. Matrix3 and Matrix4) it is
possible to use list-initialization instead of explicit type
specification:
Matrix<3, int>({1, 2, 3},
{4, 5, 6},
{7, 8, 9});
I didn't yet figure out how to properly implement the general
(constexpr) constructor to also take lists, so it's a bit ugly for now.
Matrix operations are now done column-wise, which should help with
future SIMD implementations, documentation is also updated accordingly.
I also removed forgotten remains of matrix/matrix operator*=(), which
can be confusing, as the multiplication is not commutative. Why it is
not present is explained in d9c900f076.
FeatureGroup shouldn't delete the features, as all features are deleted
in Object destructor anyway and no feature can be created without
explicitly attaching it to some Object (and it also cannot be detached).
Moreover, when the group contains two features belogning to one object
and one feature is added using multiple inheritance, on group
destruction the object gets deleted along with the feature, removing
also the other feature, which breaks the for cycle in group destructor.
Removed workarounds for alias templates, variadic templates and
anonymous enums, but 1.8.2 has some bug with forward declarations
causing classes to appear in default namespace, breaking
cross-references.
* Calling *Mesh::draw() with parameter to start on arbitrary vertex
index might give users more freedom than they want to have (e.g.
lines rendered where gaps should be, broken triangle strips...).
* Single-precision floats have meaningful precision of ~6 decimal
places, everything after that would be random garbage anyway, so we
don't need anything "more precise" for icosphere.
* Texture1D can have only one target and it can be used as framebuffer
target.
It prevents unwanted implicit conversions from e.g. nullptr to Camera,
Vector2 to Physics::Point etc. By making all the constructors explicit
it is easier to routinely add the keyword to all new classes instead of
thinking about cases when to add and when not to.
Removing of another <*stream> #include leads to more compilation time
saving, now from ~5:12 to ~4:55. Another compilation time improvements
will now be possible only by using Clang's modules, I don't know where
to optimize further (except for getting rid of <sstream> in tests).
Allows to animate objects, pause, repeat and resume the animations. The
user implements animation step and can perform actions on state changes.
Each Animable is part of some group which is optimized for case when no
animation is running, thus it is possible to create multiple independent
"animation islands" to improve performance.
Currently the documentation looked like "who would ever want something
else than 2D/3D objects", now it hints that the objects can be also on
steroids, err.., doubles instead of floats.
Now whole Magnum, Magnum::SceneGraph and Magnum::Math namespaces are
fully documented -- each class has at least "getting started"
documentation, larger modules are documented on separate pages.
Optimalizations in Corrade::TestSuite and Corrade::Utility::Debug leaded
to significant reduction of compilation time - on my machine it was
~5:38 before with building of unit tests enabled, now only ~5:00.
* In shader uniforms (projectionMatrix makes more sense than projection
alone)
* For underlying types for SceneGraph transformation. It is already
used in Drawable::clean() as transformationMatrix, so why not use it
also in AbstractFeature::clean(). Moreover, clean() could be in
future also done using something else, this helps to distinguish the
type just from parameter name.
* In Physics shapes - applyTransformationMatrix() (as it could be in
future also done using something else).
Vladimír Vondruš