The enum was only two-state, in almost all cases it included unnecessary
branching and the non-default usage was too verbose, thus all
transformation functions were split into two variants, <transform>() and
<transform>Local(). The <transform>() behaves exactly like the previous
implementation with TransformationType::Global, the <transform>Local()
behaves like the previous implementation with TransformationType::Local.
The enum and original functions were kept, they are marked as deprecated
and will be removed in future release.
This is rather large changeset, I triple checked that the new (both
deprecated and non-deprecated) implementations work as intended, but
can't possibly test every possible use case, so I'm sorry if I messed
something up :-) Also there was probably some bug in internal virtual
function implementations before, it should be now fixed.
Previously (<= 4.9.0) it behaved similarly to MSVC 2013, but the issues
with missing inline functions of classes declared as extern template
appeared again. This way doesn't work with MSVC, so I need to maintain
two separate symbol exporting scenarios. Damn you, DLL hell.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
The original purpose was to allow modifying of drawing order, but this
doesn't affect that at all (the order is preserved in DrawableGroup),
thus the functions are useless.
Previously it was possible to access internal transformation
implementation from Transformation and thus also from Object, e.g.:
typedef SceneGraph::Object<SceneGraph::MatrixTransformation2D> Object2D;
Object2D o;
o.fromMatrix(...); // What does this here and why it returns matrix?!
Now everything is hidden in Implementation namespace and all
traces of previous code are removed from documentation. It might now be
slightly harder for users to implement their own transformation
implementations, but it wasn't easy before either. The widely used ones
are already implemented, so it shouldn't be too much of a problem.
Similarly for potential backward compatibility issues, I assume nobody
needed to implement their own transformation yet.
Makes some cases less consistent (and some convenience shortcuts
impossible), but goes well with the attitude "don't use pointer when it
can't be null".
Until now, all calls to e.g. `Object::translate()` were virtual, which
is _very_ bad for performance. The virtual call is only needed when
setting the transformation via some interface, e.g.
`AbstractTranslationRotation3D`, as the caller doesn't know which
transformation implementation is used.
Now all public-facing transformation methods are inline non-virtual
functions, which are in most cases calling directly the transformation
implementation. In `Abstract*` transformation interfaces these functions
call private virtual `do*()` implementations, which are (re)implemented
in subclasses, but aren't used anywhere except when transforming
directly through the `Abstract*` interfaces. This should have good
impact on performance when doing many transformations in every frame
(although I can't verify it anywhere, as I don't have any significantly
large animated demo). Except of course when doing it through the virtual
interfaces.
As the public-facing transformation methods are now non-virtual, there
are now no "covariant return" issues and they can now return proper
`Object<*Transformation*>` type instead of just `*Transformation*`,
which makes full non-WTF method chaining possible:
Object2D* obj2;
obj2->translate({0.5f, -1.0f}) // Transformation method
->setParentKeepTransformation(obj1); // Object method
Or even this:
Object2D* obj = (new Object2D)->rotate(-15.0_degf);
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.
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.
Using header with forward declarations, containing declarations for all
classes with default parameters. The classes themselves don't have the
defaults.
This also allows users to more conveniently forward-declare instead of
digging in sources and writing the declarations on their own.
Functionality present in Object is now split into three main components:
* Object itself, handling parent/children relationships
* Transformation implementation and interfaces for common functionality
* Object features, providing transformation caching and base for
cameras, collision shapes, rigid bodies etc.
Some functionality depending on former implementation is temporarily
disabled and will be reworked later.
Vladimír Vondruš