Why did I do this:
* It is more clean, shorter and nice looking with method chaining,
i.e. instead of:
shader.setColor(...)
.setOtherParam(5);
texture1.bind(MyShader::Texture1Layer);
texture2.bind(MyShader::Texture2Layer);
We now have this:
shader.setColor(...)
.setOtherParam(5)
.setTexture1(texture1)
.setTexture2(texture2);
* It is now also clear which texture type is expected, the layer
constant did not say anything about type.
* Also it is possible to use new features (multi bind, bindless
textures etc.) while preserving the same public API.
The only potential disadvantage is that the textures don't stay bound
like uniform values do, but this become a non-issue with bindless
textures. As usual, the old way is now deprecated and will be removed in
some future release.
Each texture has slightly different usage requirements and having
everything under one generic class is not worth the additional runtime
checks and whatnot. The current way with Texture::Target enum
(hopefully not too widely used) is now deprecated and will be removed in
some future release. However general Texture1D/2D/3D usage is not
changed in any way.
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.
We need to explicitly delete copy constructors (otherwise
std::is_constructible<A, const A&>::value is true) and add passthrough
move constructors. WHY.
The point is that we accept everything except const BufferImage&, as the
buffer needs to be bound, which is not an constant operation, as it
modifies internal GL state tracker.
Can't test EXT_debug_label, as that is apparently OSX 10.9-only. Added
GL tests for all implemented objects. KHR_debug is selected first, if
that is not available, fall back to EXT_debug_label. If neither is
available, the functions are no-op.
I hope EXT_debug_label gets replaced by KHR_debug later, thus it is now
only "emulated" through KHR_debug enums.
Fixed old references to Buffer::Usage, fixed parameter order in Image
constructor, fixed some function references. Added explicit references
to linkable stuff.
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.
Buffer usage is used as parameter in many functions, e.g. in
*Framebuffer::read() and *Texture::image(), but they are rather seldom
used and including whole Buffer.h file just for one enum is just
overkill. The old Buffer::Usage is now alias to BufferUsage, it is
marked as deprecated and will be removed in future release.
Makes the lines shorter, the conversions are mainly from strongly-typed
enums to underlying type, so nothing potentially harmful which should be
marked with static_cast.
In 1.8.5 it is now possible to reference directly to enum member.
Hooray! Also added explicit @ref here and there, fixing some referencing
bugs along the way.
Passing pointer as function parameter will now mean that it is possible
to pass `nullptr`. Some code examples now look like the parameter is
copied instead of referenced, which is misleading. Updated the
documentation to reflect that more clearly.
Makes some cases less consistent (and some convenience shortcuts
impossible), but goes well with the attitude "don't use pointer when it
can't be null".
Inspired in STL, base templated class is renamed to BasicColor{3,4} and
typedef'd with Float type to Color{3, 4}. It is much nicer to write
this:
Color3(1.0f)
Color3::fromHSV(25.0_degf, 0.5f, 0.9f);
instead of this:
Color3<>(1.0f);
Color3<>::fromHSV(25.0_degf, 0.5f, 0.9f);
Avoids some nullptr-related errors and leads to simpler implementation,
as we need to only handle ImageReference and BufferImage types. All
other Image classes are implicitly convertible to ImageReference and
implicit conversion works only with references, not with pointers. The
usage might be clumsy at this point, as Trade::*Importer classes return
pointer to Trade::ImageData which then needs to be dereferenced.
Hopefully introducing C++14's std::optional (or equivalent) might help
solve that issue.
Also removed "convenience" overloads for setting e.g. 2D subdata of 3D
texture. The convenience overload doesn't cover all subdata cases (only
XY plane, not YZ or XZ ones) and overly complicates the implementation.
This can be done in the future in Image classes themselves.
Solves another trivial choice (similar to the one with TextureFormat
etc. in 7de45c98b1), less typing and also
preparation for ARB_sampler_objects extension.
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.
If ARB_invalidate_subdata is not available, these functions do nothing,
instead of crashing on null pointer dereference. It results in more
convenient usage, enabling users to call them whenever they want,
improving performance on implementations which supports that.
Vladimír Vondruš