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.
DetectedDriver::AMD is now DetectedDriver::Amd,
DetectedDriver::ProbablyAngle is now just DetectedDriver::Angle. The old
names are still present, but deprecated and will be removed in the
future.
Enabled by default, makes the current Magnum context a thread-local
variable instead of a global one, so it's possible to have multiple
thread-local contexts. Might have some performance implications, that's
why it's possible to disable it (but enabled by default is the safer
option).
GCC 4.7 and Apple platforms don't support thread_local, but __thread
does the job too (though on iOS not until Xcode 7.3). Also had to move
it to file-local because MSVC doesn't like having thread local variables
as part of DLL interface. (And there is *of course* no way to disable
exporting one particular member. F' that.)
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.
Added `--magnum-disable-extensions` option next to the already existing
`--magnum-disable-workarounds`. Specified extensions are not used
automatically and also report as disabled and unsupported when asked using
Context::isExtensionSupported() and Context::isExtensionDisabled().
The engine can now list all driver workarounds that were used during the
initialization. Any listed workaround can then be disabled from the
command-line using `--magnum-disable-workarounds` command-line
parameter. The disabling and querying API is private and undocumented,
because the driver workarounds should be disabled only by end-users and
not application developers. The workaround list is now empty, but will
be filled up in the following commits and the workarounds will be
probably documented only privately in Implementation/driverSpecific.hpp,
as it is really something that should be used only to debug driver
problems.
The parameterless Platform::Context::Context() constructor and
Platform::Context::tryCreate() function are deprecated in favor
functions that take argc/argv pair. The Context class now accepts
arguments starting with --magnum-* prefix. Currently there are none
except for the implicit --magnum-help, but that will change with the
following commits.
In some cases the GL context creation might success without error, but
the created version is one that we don't want (e.g. software GDI
rasterizer on Windows). Previously the Context class constructor just
exited the application and it was impossible to react on that from the
application side (for example reducing some context feature
requirements).
Now there is Platform::Context::tryCreate(), which returns either
created instance or `nullptr` if the instance creation failed with some
error. That is now used in all Platform::*Application implementations.
ES 2.0 extensions to match ES3/desktop functionality. The enums from
NV_pack_subimage are not available in gl.xml from Khronos, I would need
to use hardcoded value.
Just added them to the list, nothing integrated or implemented yet. Also
added some more stuff into OpenGL mapping table, as I apparently forgot
some entries.
Useful in this case:
std::optional<Platform::Context> context;
context = Platform::Context{};
This was currently possible only with calling context.emplace(), which
in my opinion is confusing and looks like a no-op. Move assignment is
still not allowed, because having two separate state trackers (and
deleting one of them) currently makes no sense.