In the particular case of AnyImageConverter the function needs to access
manager and load/instantiate plugin using it, which is non-const
operation. More generally, it puts unnecessary restrictions on what the
plugin can and cannot do.
Provide a way to convert compressed images to data/file (i.e. saving
DXT5-compressed image data to DDS file), improve feature flags so that
the plugin can properly advertise what's supported (for example some
plugin may just be able to compress RGBA to DXT5, but not to save that to
DDS file).
This is backwards-incompatible API breakage (renamed enum value), but
because the original API wasn't in any official release yet, I'm not
doing any deprecation and backwards compatibility.
I can't believe that you can just forget to include some file and it
will SILENTLY PASS and then crashes horribly at runtime because each
translation unit thought that given member function pointer had
completely different size. THIS IS NOT ACCEPTABLE.
It worked flawlessly when crosscompiled from Linux, but compiling that
natively causes the linker to loudly complain about undefined references
to ConfigurationValue structs. I think it worked well under 4.9.2 (but
that mess had a slew of other ugly problems, such as complete inability
to produce non-crashing C++11 code under x64). The linker error is
caused only because I tried to reduce binary bloat, so I'm just
disabling that for MinGW and screw that. No problem under MSVC.
I don't know why, but marking the output of copy constructor of any
subclass or output of conversion operator of any class as constexpr
causes MSVC to complain about non-constant expression.
Probably just another bug.
Also probably fixed a few issues when compiling the shader on older GLSL
and GLSL ES (floating point literal suffixed, missing precision qualifiers).
And less crazy preprocessor.
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.
ES 2.0 extensions to match ES3/desktop functionality. The enums from
NV_pack_subimage are not available in gl.xml from Khronos, I would need
to use hardcoded value.
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).
Vladimír Vondruš