It was just RGB before. In order to avoid breaking current code, the
attribute now requires explicit specification of number of components.
If building with deprecated APIs enabled, there is an additional
deprecated constructor that defaults to RGB so the current code should
keep working as-is.
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.
Each shader now has sample image, example mesh configuration and example
rendering setup. Also properly documented all attribute types and made
introductory chapter for whole Shaders namespace.
As we are now using absolute includes, there is no need to prefix
everything with "magnum<Namespace>" etc. All generated configuration
files are renamed to configure.h and their path is included _before_
everything else to avoid accidental collisions.
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.
Defines common attributes which are shared by majority of the shaders,
allowing mesh to be configured for the generic shader to be used with any
of them.
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".
Inspired in STL, base templated class is renamed to BasicColor{3,4} and
typedef'd with Float type to Color{3, 4}. It is much nicer to write
this:
Color3(1.0f)
Color3::fromHSV(25.0_degf, 0.5f, 0.9f);
instead of this:
Color3<>(1.0f);
Color3<>::fromHSV(25.0_degf, 0.5f, 0.9f);
Originally it was for more convenient usage of homogeneous coordinates
in shaders themselves, but it is actually not needed:
* When passing three-component vector (3D position) to `vec4`, the last
coordinate is implicitly set to `1`, thus there is no need to pass it
explicitly in each attribute.
* On the other hand, when passing three-component vector (2D position
in homogeneous coordinates) to `vec3` with Z explicitly set to `1`,
it still needs some swizzle magic to extend it to `vec4` gl_Position.
Passing it as two-component vector results in nearly the same magic
while saving precious memory.
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).
It was mainly in DimensionTraits usage. Also using DimensionTraits::*Type
for private members of physics shapes instead of manually specified
superclasses. The header is still included because of all the inline
accessors, so why not use the same type inside the class.
Vladimír Vondruš