103% of use cases use the returned value directly without checking, so
we might as well do the check ourselves. Added new function hasCurrent()
and added deprecated backward-compatibility conversion and -> operators.
Wow, that creeped to a lot of places.
Last dinosaur from the pointer age.
It returns different value based on whether the cube map is immutable
(allocated using setStorage()) or a sequence of setImage() calls, well,
at least on my NVidia. That should not happen, workaround incoming.
I'm experiencing weird inconsistencies when querying
GL_TEXTURE_COMPRESSED_IMAGE_SIZE on cube map textures, it seems to
depend on whether the texture is complete/immutable or not, this is a
first part of an attempt to nail it down.
It is a valid usecase, e.g. when saving a screenshot in an oneliner:
pngImageConverter->exportToFile(defaultFramebuffer.read(
defaultFramebuffer.viewport(), {PixelFormat::RGB,
PixelType::UnsignedByte}), "screenshot.png");
Mesa properly complained that S3TC isn't supported on 3D textures using
GL error (good), while AMD and NV had both their own unique data
corruption/random shuffling (bad!).
BPTC is available only on desktop, will have to wait until ASTC HDR is
more widely available.
Mesa drivers (rightfuly) complained that S3TC is not supported on 3D
textures, the packing had weird behavior on NVidia but it passed w/o
problems on AMD. Now should be okay on all three, yay!
Pain and misery. Majority of functionality for 3D compressed images now
suddenly fails the test -- this is either very vaguely specified or I am
very bad at understanding things or there are bugs in my NVidia drivers.
This was awful feature. Kill me now.
Makes it far easier to detect pixel storage misconfigurations and
improperly sized data arrays. Data owning classes (Image,
Trade::ImageData) accept Containers::Array<char> while wrappers
(ImageView, BufferImage) accept Containers::ArrayView<const void>.
ImageView reinterprets the passed array as const char to enable pointer
arithmetic on the data.
The old way (constructor/setData() call accepting void*) is now marked as
deprecated and will be removed in some future release. Because decay of
fixed-size arrays to void* is preferred to calling Containers::ArrayView
constructor, there are two more overloads to have proper handling of
const T(&)[n] and std::nullptr_t arguments.
Currently the TgaImporter and TgaImageConverter fail on images with row
length not aligned to 4, will fix that in followup commits.
Removed *Image::dataSize() and added *Image::dataProperties(), which
returns all properties separately for better introspection. This function
is now just an convenience alias to PixelStorage::dataProperties(), which
takes into account proper alignment and all other storage properties.
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.
Vladimír Vondruš