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.
It was returning either pixel size or compressed block size, which is
now available directly via other means.
This is a breaking change, but I don't expect these functions to be
used widely beyond Magnum internals.
With the previous commits the original tests passed (which is
desired), but these were using deprecated functionality and not
covering the new stuff. These tests are not using the deprecated
functionality, which means I don't need to build them as part of
the GL library anymore.
The GL::BufferImage test is still using the deprecated
functionality though, in order to check I didn't break anything
by accident.
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.
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.
Too much burden to implement. Nope. Sorry. All APIs were just asserting
that it's not enabled at the moment, so I may as well just remove it
completely.
The `#line` statement was an ugly hack and it breaks code highlighting
in KDevelop (and I guess in many other Clang-based IDEs as well). This
however means adding new extensions is a bit more annoying, but
hopefully the newly added test should aid with that. Developers guide
contains more info.
Since 98a676ef65, on ES2 and WebGL1 the
Texture::setStorage() emulation passes the pixel format to both <format>
and <internalFormat> of glTexImage() APIs. On desktop the go-to way to
create a sRGB texture is by passing GL_SRGB to <internalFormat> and
GL_RGB to <format>, but here GL_RGB was passed to both and thus the
information about sRGB was lost.
With the new PixelFormat::SRGB and PixelFormat::SRGBAlpha enums that
are present only on ES2/WebGL1 this case is fixed -- sRGB texture format
will get translated to sRGB pixel format and that used for both
<format> and <internalFormat>.
Another case is when EXT_texture_storage is available -- passing unsized
GL_SRGB_EXT or GL_SRGB_ALPHA_EXT to glTexStorageEXT() is an error and
there's apparently no mention of this in any extension, making it
impossible to create sRGB textures using EXT_texture_storage. I bit the
bullet and tried passing the (numerical value of) GL_SRGB8 and
GL_SRGB8_ALPHA8 to it. At least on my NV it worked, so I enabled these
two in TextureFormat for ES2. No EXT_texture_storage is on WebGL1, so
they are only on ES2.
These two sized TextureFormat::SRGB8 and TextureFormat::SRGB8Alpha8
formats are translated to GL_SRGB and GL_SRGB_ALPHA and so using them
unconditionally for all platforms (except WebGL1) "just works".
There's a new DynamicAttribute class that is very similar to Attribute,
but it has the location and base type as runtime properties instead of
them being a part of template. This allows for more flexibility, but
OTOH also more typing and more responsibility on the user. See
MeshGLTest for details and usage comparison to the Attribute API.
Fails. Problem spotted on WebGL 2 and is an unfortunate consequence of
these events:
1. Neither EXT_DSA nor ARB_DSA is available, but VAOs are available,
which means virtually all ES 3 and WebGL 2 implementations and also
ES 2 / WebGL 1 with OES_VAO available.
2. Index buffer gets created with TargetHint::ElementArray, bound to
GL_ELEMENT_ARRAY_BUFFER and filled with data.
3. Mesh object with VAO inside is created and the index buffer from
above gets bound to GL_ELEMENT_ARRAY_BUFFER again to attach it to the
VAO.
4. Another index buffer, possibly for another mesh, gets created with
TargetHint::ElementArray and bound to GL_ELEMENT_ARRAY_BUFFER in
order to be filled with data. But because the VAO from above is still
bound, the index buffer attachment is then stomped on.
5. Rendering such mesh will use a different index buffer, most probably
causing some out-of-range GL error and nothing rendered.
DetectedDriver::AMD is now DetectedDriver::Amd,
DetectedDriver::ProbablyAngle is now just DetectedDriver::Angle. The old
names are still present, but deprecated and will be removed in the
future.
The GL queries are needed only if the user-provided pixel storage
doesn't contain enough information, in particular dimensions and byte
size of compression block.
So in case they are present, no query for compressed image size is done
for full image queries (just saving one API call) and no queries for
block dimensions and byte size for subimage queries (saving four API
calls and not requiring ARB_internalformat_query2).
The documentation was fixed and tests were updated to take the
ARB_internalformat_query2 requirement into account.
There were various issues with the tests at the moment:
* In order to test non-default pixel storage parameters, out-of-bound
array slices were passed to GL functions. That of course cause ASan
to complain (and maybe also some drivers to crash).
* Only the non-default pixel storage parameters were tested.
Unfortunately this is a heavily buggy area in all the drivers, so
when such a test failed, it was not immediately clear whether the
failure is related just to driver not understanding pixel storage
properly or something deeper and made debugging much much harder than
it should be.
* For compressed textures, default and non-default pixel storage has
grossly different code paths and these should be tested both by
default.
* Some test cases had a patched-in code testing for both default and
non-default pixel storage, but the code was so hidden that I didn't
even know it was there -- it should be separate test cases.
All the tests are now instanced, testing both the simple case and
some pixel storage case, they are also reordered and cleaned up a bit.
Vladimír Vondruš