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.
Enabled by default, makes the current Magnum context a thread-local
variable instead of a global one, so it's possible to have multiple
thread-local contexts. Might have some performance implications, that's
why it's possible to disable it (but enabled by default is the safer
option).
GCC 4.7 and Apple platforms don't support thread_local, but __thread
does the job too (though on iOS not until Xcode 7.3). Also had to move
it to file-local because MSVC doesn't like having thread local variables
as part of DLL interface. (And there is *of course* no way to disable
exporting one particular member. F' that.)
Similarly as it is done in STL for C++14 literals, the user has to
explicitly put them to scope with `using` keyword to avoid accidental
collisions. If MAGNUM_BUILD_DEPRECATED is set, they are still brought to
the root namespace, but that will be removed in a future release.
Allows to break the dependency on the <Magnum/CubeMapTexture.h> header
in Framebuffer, TextureState and elsewhere. The old
CubeMapTexture::Coordinate enum is now just an alias, is marked as
deprecated and will be removed in a future release.
Toggles between using CGL/GLX/WGL (requiring running graphical desktop
environment) or EGL (without display attachment) for command-line
utilities and GL tests. Also exposed to the user through
MAGNUM_TARGET_HEADLESS CMake and preprocessor variables.
Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
I hoped to use them to store pixel pack/unpack configuration, but I have
better solution now.
The AbstractImage.h header is now removed along with the base classes,
I'm not expecting that anyone used these empty classes, so I'm not doing
anything to preserve backwards compatibility.
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.
Added (now empty) AbstractCompressedImage class that inherits (now also
empty) AbstractImage class.
Added CompressedBufferImage, CompressedImage and CompressedImageView
classes, which are just copies of BufferImage, Image and ImageView
classes with format/type pair replaced by just format, but they
additionally need data size parameter.
Because of different use cases in Trade, the Trade::ImageData class now
handles both uncompressed and compressed format, checking the API
usage with runtime assertions. The reason for this is that a material
could just reference a image file by ID and we need to be able to
extract image of that ID without prior knowledge whether it is
compressed or not. Requiring prior knowledge of image format from the
user would make both the API and the usage far more complicated than
having Trade::ImageData which handles both cases.
On the other hand, the Image*/CompressedImage* distinction is done for
easier usage and type-safe APIs in all other cases.
Vladimír Vondruš