Was Magnum::GL::Extensions::GL before and the redundancy was completely
unnecessary. Potential future extensions coming from GLX, EGL or whatnot
will most probably be in the Platform namespace in a completely separate
file, so this is not a problem.
All code internal to the GL library is affected, not much the outside,
as that is handled by the compatibility alias.
At the moment just the GL library itself w/o the tests, and without
backwards compatibility aliases. The following types were left in the
root namespace, despite being in the GL/ directory, as they will get
moved back soon:
* Image, CompressedImage and their dimensional typedefs
* ImageView, CompressedImageView and their dimensional typedefs
* PixelStorage
Not PixelFormat etc., that one will stay in the GL namespace and a
completely new PixelFormat enum will be provided in the root namespace.
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
They were utterly confusing, as it was completely unclear what the units
of offset/size parameters are, whether byte sizes or element counts (and
moreover, some of these APIs had offset in bytes and size in count and
some not). All of those are deprecated now, with hinting the user to
convert to non-templated APIs in combination with
Containers::arrayCast(). Moreover, the non-templated range map()
function doesn't return just void* anymore, but a properly sized
ArrayView<char>. The old map() (which doesn't take range) still returns
just a pointer (but also a char* instead of void* for consistency), as
getting size there is non-trivial (and impossible on old ES/WebGL).
The switch to ArrayView might be a source breaking change, but I
silently hope that everyone was just using the templated functions
anyway (that are deprecated now). So, in short, this was before:
T* a = buf.map<T>(0, size_in_what_i_have_no_idea);
And this is now, with proper size safety and clear API:
ArrayView<T> a = Containers::arrayCast<T>(buf.map(0, size_in_bytes);
The deprecated APIs will be removed at some point in the future, as
usual.
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.
Full support for EXT_transform_feedback, transform feedback objects
from ARB_transform_feedback2 and equivalent OpenGL ES 3.0 functionality.
Example usage is in src/Magnum/Test/TransformFeedbackGLTest.cpp, I'll
add some example later.
The indexed binding is allowed for only some types (atomic counters,
uniforms, shader storage and transform feedback), thus we need separate
enum for that. Because the bind() function will be used far more often
than setTargetHint(), the original Target enum is now renamed to
TargetHint and the new Target enum contains (in non-deprecated build)
only three values.
For backwards compatibility, though, we need to have all original Target
values, thus the new Target enum contains also all other values from
TargetHint, but they are marked as deprecated and (at least) run-time
checked in bind() so they aren't accidentaly used for indexed binding.
Similarly there are also deprecated Target overloads of Buffer() and
setTargetHint(). It's ugly, but hopefully will suffice for now. This mess
will be removed as soon as possible in some upcoming version.
Previously 0 was returned, which would fail at runtime for
division-by-zero in the following sanity check:
CORRADE_INTERNAL_ASSERT(!(offset % BufferTexture::offsetAlignment()));
There should be no need to use these directly (and in some cases it
might be harmful). The bind()/unbind() names will be used for
glBindBufferBase()/glBindBufferRange() later.
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.
This smells fishy. The function _does have_ a no-op fallback
implementation to remove the need to wrap everything with an #ifdef
and/or extension check, so why I did exactly that everywhere?