Use AbstractFeature<dimensions, T>, AbstractGroupedFeature<...>,
AbstractFeatureGroup<...>, FeatureGroup<...> like before and add two
kinds of aliases instead of only one, one with *Basic* for abstract type
and one for Float type.
Partially reverts commit 572efce3f7.
Use AbstractObject<dimensions, T> like before and add two kinds of
aliases instead of only one:
AbstractBasicObject2D<T>/AbstractBasicObject3D<T> for abstract type and
AbstractObject2D/AbstractObject2D for Float.
Makes it easier to use AbstractObject in templates of fixed dimensions
(e.g. Bullet integration, where it can now be written as
`AbstractBasicObject2D<btScalar>` instead of potentially confusing
`AbstractBasicObject<2, btScalar>`).
Partially reverts commit cfd405c32c.
Constructor, destructor and all virtual functions are moved into
implementation file, so they don't need to be recreated and add into
binary on every usage. Should save a bit on resulting file size.
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.
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.
* 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).
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š