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).
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.
I got like five e-mails about this already, putting that in the docs so I
don't have to invent that every time again.
This is very specific to many transformation/projection properties
(origin, Y up, 2D/3D and whatnot) and thus I'm not adding any convenience
function to calculate that.
Currently the user had to ensure that buffers added to mesh were not
moved at all, which was very annoying, basically each one of them had to
be allocated on heap. Now the Mesh stores a weak copy (yes, really) using
Buffer::wrap() with no deletion on destruction, so the original instance
can be freely moved around without any fear of crash.
Thanks to @Squareys for the original idea/request about wrap() functions,
really useful part of the API.
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.
It might happen that the user is calling ARB_DSA-only functions like
CubeMapTexture::subImage() the texture was created using glGenTextures()
and not using ARB_DSA, for example because the extension was disabled
and then not bound or used at all, which makes the texture "not created
yet". This is not needed for internal (...ImplementationDSA()) functions
because these are always called only if the texture was also created
using glCreateTextures(). Basically doing the same that's in
AbstractTexture itself but for some reason was omitted here.
The internal ...ImplementationDSA() functions might break in case the
object is created externally using glGen*(), not bound or used at all and
then the class is created using ::wrap(), but that's highly unprobable
(why would anyone do that?).