Its only use was for specifying N-dimensional SamplerWrapping because,
compared to a Math::Vector, it had an implicit constructor from a single
value (whereas the Vector has it explicit). I solved that by simply
adding a few single-value overloads where it mattered. There, done. No
need for this weird thing and confusion with Containers::Array anymore.
All places that used it now use Math::VectorN<SamplerWrapping>, but the
class is still included for backwards compatibility purposes, together
with providing implicit conversion from and to a Vector.
Same as in Corrade. Because BUILD_STATIC is independent between Corrade
and Magnum this option is also independent -- the corner cases and bad
interactions would be otherwise too complex to handle (e.g., in case of
a dynamic Corrade and static Magnum it would be impossible to enable
this option for Magnum etc etc).
This deliberately doesn't follow the PixelFormat enum naming, as RGBA
components make no sense for most vertex data. Checking Metal and
WebGPU, they seem to have arrived at a similar conclusion, only VkFormat
is an outlier.
Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
If building with deprecated features enabled, the buildsystem checks if
the option is still set and is inconsistent with what Corrade reports
and reports a deprecation warning. For backwards compatibility the
MAGNUM_BUILD_MULTITHREADED CMake variable and preprocessor macro are
still provided as well.
Pros:
* faster compile times (#include <tuple> is 13k lines, ugh)
* ability to have NoInit and ZeroInit constructors
* ability to do fuzzy compare
* named members, so we don't have to use mutable std::tie()
Cons:
* ... none?
The old Color[34]::Hsv is still a tuple and the new ColorHsv is
convertible to/from it (and even std::tie() works). These are all
deprecated (along with the <tuple> include).
Deprecated for 2018.04, it's been almost a year since. Whoever is using
Magnum regularly updated already, and who not can always upgrade
gradually (2018.02, 2018.04, 2018.10, 2019.01 etc.).
It'll get used outside of the root namespace and since the callbacks tend
to be quite complex, it would be silly to require users to implement one
callback for Trade, one for Text and one for Audio, for example.
Deprecated in 52f2d297ca (April 2016), but
never actually causing any warning, so very annoying to deal with.
Explicitly call `using namespace Math::Literals;` instead.
The Sampler class was split into GL::Sampler (which is now mostly just a
placeholder for implementing OpenGL sampler objects), pairs of generic /
GL-specific SamplerFormat / GL::SamplerFormat, SamplerMipmap /
GL::SamplerMipmap, SamplerWrapping / GL::SamplerWrapping enums and the
GL-specific GL::SamplerCompareMode, GL::SamplerCompareFunction,
GL::SamplerDepthStencilMode enums.
The old Sampler class is marked as deprecated and aliases its enum to
the generic enums (or to the GL-specific ones in case the generic
versions are not available).
Similarly to pixel formats, there is now generic Magnum::MeshPrimitive
and Magnum::MeshIndexType, which is convertible to GL::MeshPrimitive and
GL::MeshIndexType using GL::meshPrimitive() and GL::meshIndexType(). In
addition, the following is done:
* The original GL::Mesh::IndexType is now GL::MeshIndexType, original
name is now just a typedef.
* GL::Mesh::indexSize() is deprecated in favor of
Magnum::meshIndexTypeSize() and GL::Mesh::indexTypeSize().
* New GL::Mesh::indexType() and GL::MeshView::mesh() getters (not sure
why they were omitted)
* GL::Mesh::indexType(), GL::Mesh::indexTypeSize(),
GL::MeshView::setIndexRange() now expect that the mesh is indexed
(useful property in my opinion, also avoids getting random results).
* The extra MeshPrimitive::LinesAdjacency etc. are still present for
backwards compatibility, but marked as deprecated. Use
GL::MeshPrimitive values instead.
This is quite big, so:
* There are new Magnum::PixelFormat and Magnum::CompressedPixelFormat
enums, which contain generic API-independent formats. In particular,
PixelFormat replaces GL::PixelFormat and GL::PixelType with a single
value.
* There's GL::pixelFormat(), GL::pixelType(),
GL::compressedPixelFormat() to convert the generic enums to
GL-specific. The mapping is only in one direction, done with a lookup
table (generic enums are indices to that table).
* GL classes taking the formats directly (such as GL::BufferImage) have
overloads that take both the GL-specific and generic format.
* The generic Image, CompressedImage, ImageView, CompressedImageView,
and Trade::ImageData classes now accept the generic formats
first-class. However, it's also possible to store an
implementation-specific value to cover cases where a generic format
enum doesn't have support for a particular format. This is done by
wrapping the value using pixelFormatWrap() or
compressedPixelFormatWrap(). Particular GPU APIs then assume it's
their implementation-specific value and extract the value back using
pixelFormatUnwrap() or compressedPixelFormatUnwrap(). There's also an
isPixelFormatImplementationSpecific() and
isCompressedPixelFormatImplementationSpecific() that distinguishes
these values.
* Many operations need pixel size and in order to have it even for
implementation-specific formats, a corresponding pixelSize()
overload is found via ADL on construction and the calculated size
stored along the format. Previously the pixel size was only
calculated on demand, but that's not possible now. In case such
overload is not available, it's possible to pass pixel size manually
as well.
* In order to support the GL format+type pair, Image, ImageView and
Trade::ImageData, there's now an additional untyped formatExtra()
field that holds the second value.
* The CompressedPixelStorage class is now unconditionally available on
all targets, including OpenGL ES and WebGL. However, on OpenGL ES the
GL APIs expect that it's all at default values.
I attempted to preserve backwards compatibility as much as possible:
* The PixelFormat and CompressedPixelFormat enum now contains generic
API-independent values. The GL-specific formats are present there,
but marked as deprecated. Use either the generic values or
GL::PixelFormat (togehter with GL::PixelType) and
GL::CompressedPixelFormat instead. There's a lot of ugliness caused
by this, but seems to work well.
* *Image::type() functions are deprecated as they were too
GL-specific. Use formatExtra() and cast it to GL::PixelType instead.
* Image constructors take templated format or format+extra arguments,
so passing GL-specific values to them should still work.
At the moment just the GL library itself w/o the tests, and without
backwards compatibility aliases. The following types were left in the
root namespace, despite being in the GL/ directory, as they will get
moved back soon:
* Image, CompressedImage and their dimensional typedefs
* ImageView, CompressedImageView and their dimensional typedefs
* PixelStorage
Not PixelFormat etc., that one will stay in the GL namespace and a
completely new PixelFormat enum will be provided in the root namespace.
This will later enable conditional compilation of APIs that depend on
the GL library (for example the Text library directly producing compiled
meshes instead of just plain vertex data).
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
At first I designed a hugely disrupting change that basically deprecated
everything related to 8-bit linear RGB colors, but then I took a step
back and reconsidered 8-bit linear RGB as a valid use case.
The documentation of Color classes, typedefs and literals was clarified
to mention that these classes should always represent linear RGB and
that 8-bit colors are commonly treated as *not* linear and one should be
aware of it.
There is now a new Color3::fromSrgb() and Color3::toSrgb() that converts
from sRGB representation to a linear RGB usable for calculations and
then back. For four-component colors, there is now
Color4::fromSrgbAlpha() and Color4::toSrgbAlpha(). Similarly to what
OpenGL sRGB behavior is regarding to alpha, the alpha channel is kept
linear, that's why I'm also calling it sRGB + alpha instead of sRGBA.
Besides that, there are four new literals _srgb, _srgba, _srgbf and
_srgbaf that have different semantics to support the sRGB workflow. The
8-bit versions are equivalent to _rgb and _rgba, though they don't
return Color3 but a non-color Vector3 to hint that the result is not a
linear RGB color. Main purpose of these is documentation. The float
versions apply an inverse sRGB curve to the input, returning a linear
RGB color.
Vladimír Vondruš