What's left is *a lot* of places taking monstrous
std::vector<std::reference_wrapper> and that can't be changed to
std::vector<Containers::Reference> in a source-compatible way. Even that
would be only a temporary change, since the goal is to fully avoid
dependency on STL in those cases.
The final version of these APIs should take
Containers::ArrayView<Containers::Reference> and be implicitly
convertible froom e.g. std::vector<Containers::Reference>. That's
definitely possible, but not in time for 2019.01, so instead of forcing
users to temporary pass a `{vec.begin(), vec.size()}` everywhere instead
of just `vec`, I'm rather keeping these APIs intact.
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.
A bunch of extensions formerly in AEP are now part of ES 3.2, which
means they were reordered in the extension lists. While at it, also
added corresponding new GL and WebGL extensions and fixed a few wrongly
categorized extensions in WebGL.
What this changes:
* Before, a Version::GLES310 shader was created with `#version 450`
directive, which is wrong, because an implementation might support
GLES 3.1 but not GL 4.5 so this was not working and also the syntax
is a bit different so this wasn't helpful at all.
* Similarly, Context::isVersionSupported(Version::GLES310) was checking
for support of OpenGL 4.5. Now it just checks for
`ARB_ES3_1_compatibility` extension.
* Added a small isVersionES() utility that just tells whether given
version is ES or not.
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.
Intel drivers on Windows print out "No errors." when the shader is
compiled/linked successfully. I consider that as unnecessary spam and
filter it out.
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.
Because Debug outputs chars as numbers, it displayed the following:
compilation of fragment shader321 succeeded ...
compilation of vertex shader322 succeeded ...
instead of
compilation of fragment shader 1 succeeded ...
compilation of vertex shader 2 succeeded ...
Now I will forever know that ASCII code of space is 32.
As g_truc said long ago:
https://twitter.com/g_truc/status/352778836657700866
Currently there is not much use of this as the stock shaders are
compiled one by one (and doing it differently would make things
needlessly overcomplicated), but the users can do parallel compilation
of their own shaders.
Also removed a bunch of now-unneeded TODOs and made the linker/compiler
code nearly similar. Also the whole Shader::compile() call now does two
allocations in total instead of two allocations for each shader.