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".
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.
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.
When pixel pack/unpack parameter support is done, this class will
contain only stuff that's common to both compressed and uncompressed
images. Currently that's nothing, so the class is empty.
Note the hilarious bug in both GCC and Clang: if you remove the `_dummy`
member, both of them start complaining about weird completely unrelated
stuff.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Until recently (or maybe not too recently) ES3 extension header was
"currently empty", now the extension header is shared with ES2. It's
nice to finally get rid of all the weird ifndefs.
It is deprecated, but many ES2 implementations don't support
EXT_texture_rg, thus this is the only way to have single- and
two-component textures without wasting precious memory. The enum value
isn't exposed on desktop OpenGL and ES3. GL_ALPHA is not supported, as
it doesn't bring any new functionality (it is also single-component
and thus can be interchanged with GL_LUMINANCE).
Advantages:
* The enums were large (600-800 lines) and they polluted the header,
now they are in separate files (except for BufferTexture, which has
the enum small enough to be left in the same file).
* Image classes now don't need to include OpenGL headers, as they were
needed only for the enum values. With advantage of C++11's forward
enum declarations there is no need to include the enum headers
anywhere in implementation, only when particular values are needed.
* The values are now less verbose:
AbstractTexture::InternalFormat::RGB8 // before
TextureFormat::RGB8 // now
* Resolved another "trivial choice" problem (thanks @JanDupal for
introducing this term to me): how to specify the format if there are
ten ways to do it (some being massively confusing):
Image2D::Format f = AbstractImage::Format::RGB; // too long...
Image2D::Format f = Image3D::Format::RGBA; // why 3D? this works?
Image2D::Format f = BufferImage1D::Format::RGBA; // wat?
It is even worse (and more verbose) with textures:
Texture2D::InternalFormat f =
CubeMapTextureArray::InternalFormat::RGB8; // this is allowed?
To have consistent naming this change was done also with
BufferTexture::InternalFormat (now BufferTextureFormat), although there
were no trivial choice issues and the enum isn't too large. But at least
it is now less typing.
Optimalizations in Corrade::TestSuite and Corrade::Utility::Debug leaded
to significant reduction of compilation time - on my machine it was
~5:38 before with building of unit tests enabled, now only ~5:00.
Desktop OpenGL and OpenGL ES 2 support can be switched using CMake
TARGET_GLES option. All functionality not supported in ES is marked in
documentation.
If targetting OpenGL ES, GLES2/gl2.h is included instead of GLEW.
Mesh class now uses VAOs only in desktop OpenGL, in ES the buffers are
bound on each draw call.
* Framebuffer related functions moved to Framebuffer class, thus
simplifying the data setting functions - removed setDimensions(),
more flexible setData() function.
* Allow to set data with explicit format specification, reorganized
function parameters to make these two setData() more similar.
* Now using new AbstractType::ComponentType enum instead of basic Type,
updated TypeTraits to return the new enum from imageType() function.
These classes are meant to be used in the same texture updating
functions as Trade::ImageData due to static polymorphism. In addition to
Trade::ImageData, which is read-only, these classes support updating the
dimensions and data. Image2D and ImageBuffer2D can update the data also
from framebuffer.
It was overengineered and unnecessarily complicated. Now the camera is
specified only in Scene::draw(), which eliminates all the needs for
recalculating absolute object transformations on each camera
transformation change. Absolute object transformation is now computed
relative to root object or relative to camera object passed as
parameter. Because of that it is now also possible to draw the scene
using multiple cameras at once.
Vladimír Vondruš