ARB_direct_state_access doesn't have equivalent for glTexImage*D(),
which indicates that these calls should not be used anymore. Also
removed EXT_direct_state_access code path and kept just the plain
glBindTexture() + glTexImage*D(), as I assume that all implementations
which have EXT_DSA have also ARB_texture_storage, thus this alternative
would have no use.
In most cases the label is set directly from code, e.g.:
texture.setLabel("diffuse-duck");
Avoiding conversion to std::string and passing char(&)[size] directly
will avoid one allocation and deallocation. Better solution would be to
use std::string_view everywhere, but we're not in C++17 yet.
Until now the textures were bound to layers, which was rather confusing,
especially when binding layered textures to layers (gaah). Also the
wording might have implied that each texture must be in some layer in
order to make it usable in shader. This is no longer the case with (yet
unimplemented) bindless texture, so another reason to remove the
confusion.
All occurences of texture layers were replaced texture binding units to
follow OpenGL naming. It was mostly in the docs, except for
already-deprecated *Layer enums in shaders, but they will be removed
soon anyway.
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.