The quality of this compiler just reached a new low. Getting memory
corruption just because I didn't include the header which isn't needed
by any other compiler?! What?!
Currently named as "removed" until I find a word which is *even* amount
of characters shorter than "supported" ("disabled" is not and it looks
ugly). Also marked extensions that can't be supported in current GL
version with "n/a" instead of "---".
Previously the extensions were either disabled altogether (e.g. because
we don't have yet extension wrangler on ES) or had manually adjusted
minimal required versions to avoid issues on older versions (e.g.
ARB_explicit_attrib_location is known to give compiler errors when used
with GLSL < 1.50 on some drivers), both done basically at compile time
unrelated to actual hardware/driver used.
Now all the extensions are enabled exactly as the driver advertises them
(or when their core version is not larger than the context version) and
have minimal required versions as per specification. Given extension is
supported in given version when it is marked as such and its minimal
required version is not larger than the requested one. The extension
disabling is thus done by simply increasing the minimal required version
to larger value (or Version::None for disabling it for all versions).
Currently no such disabling is put into place, but the existing
workarounds scattered all over the place will be gradually converted to
this.
Simplified the code and tests by marking all extensions from previous
versions as supported instead of additional "shorthand" checking whether
extension's core version is supported. The check wasn't probably much of
a speedup, as it was just another branch. This was also buggy
previously, because when the extension would be reported as not being
supported in older versions, which is not what we want. Hopefully this
won't reintroduce the numerous issues with Mesa and OSX I had in the
past :-)
Also removed duplicate implementation of
Context::isExtensionSupported(), one overload is now calling the other.
GCC 4.7 cannot detect proper overload based on arguments in initializer
list constructor of some type, thus we need to provide explicit overload
taking std::initializer_lists.
Found thanks to (probably otherwise useless) GCC warning about usage of
deprecated function . Clang didn't emit such warning, because
even deprecated function should be able to call itself recursively.
Currently all the functions taking vectors of objects (e.g. setClean(),
transformations() and transformationMatrices()) were taking pointers,
which lead to additional (and often forgotten) nullptr checks. The
internals are now much more clean, as the parts where we are dealing
with pointers are reduced to bare minimum.
Also renamed private Object::setClean() function to
Object::setCleanInternal() to avoid overload clash with the public one.
The old way is now an nullptr-checked alias to the new one, is marked
as deprecated and will be removed in some future release.
*Texture::bind() is now meant to be used only internally from shaders,
thus this function is not needed at all, as we should query directly the
particular shader type for the limits.
The name also somehow clashes with layered textures, which should be
avoided.
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.
Previously the API didn't encourage the user to set up and activate
shader before drawing the meshes, leading to unintuitive behavior:
// Can I just call draw() or do I have to fully understand the
// meaning of the universe before?
mesh.draw();
Now the draw() needs the shader passed explicitly as parameter, which
should hint that the shader must be set up somehow:
// Right, so this needs just a shader and that's all. Expecting this
// I fortunately *did* configure all the uniforms before this call.
mesh.draw(shader);
It is also possible to pass the shader as rvalue, in case the drawing is
just a one-off thing and is already fully configured.
mesh.draw(MyShader{});
As usual, the original API is kept, is marked as deprecated and will be
removed in some future release.
Vladimír Vondruš