The GL::Renderer::setClearDepth() and setDepthRange() APIs now use the
non-clamping NV entrypoints if available. The float overloads do that
too, to avoid differences in behavior depending on whether these
functions are called with a float or a double type.
To match ARB_texture_view from from GL 4.3. Not sure why there's two of
them -- I was looking into the spec files, and the EXT variant seems to
be based on the OES variant but doesn't seem to add any change (or, no
change is listed), however the OES variant has number 218 while EXT has
185 so it's actually newer?! No idea what's happening there.
These two options were mutually exclusive, and both were doing the same
thing -- switching to EGL on desktop GL, or switching away from EGL on
GLES. That made all logic vastly more complicated than it should be, and
unfortunately it took me half a decade to realize that. The new logic is
significantly simpler everywhere.
As usual, the old options are still recognized by CMake on a deprecated
build (with a warning), and are still exposed both as CMake variables
and a preprocessor define. But the logic for them was quite complicated,
so I don't guarantee all cases are covered.
I also tried to clean up the dependent CMake options to allow building
GLX and WGL apps on GLES independently of whether EGL is used, but it's
quite a mess due to the limitations of CMake < 3.22. Build directories
that have the options switched randomly over a long time might start
misbehaving, but the initial build should work well.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
Yay, I can abuse/reuse the features I had to add to flextGL because of
GOOGLE!!!, and with only one additional patch to support local xml
files I can very conveniently include whatever entrypoints I need.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Got done in 7ced4740fd and
f3fc17e2b0 for CGL and OpenAL, but ever
since Travis decided we're not worthy of using their services, I didn't
have a chance to check the warning in the iOS build. Now I have.
Was browsing the extension registry looking for something else and found
this instead. It used to be ES catching up with desktop, now it's the
other way around.
We're not including windows.h there (fortunately!), so there's no point
in defining such a macro. Also the proper way would be defining it only
if it's not already defined to avoid macro redefinition warnings.
These are in most cases the only strings that are used, and I don't
think having to call std::strlen() for each of them is a good idea if
we don't need to.
We're going to eventually include this class in all Application classes
(need that in order to inherit a to-be-created Configuration class) and
the <string> and <vector> would be just too much. This change caused
magnum-gl-info.wasm (WebGL 2 build) to go down from 247 to 245 kB. Not
much, but that's I guess because there's still a lot other vectors of
strings elsewhere.
There's a lot more places to clean up, will do those in separate
commits. This change is the most atomic I could do, and it introduces a
breaking change to all APIs that returned a std::vector or a
std::string. Fortunately (or as I hope) those weren't used that much, so
it shouldn't cause build breakages for that many people.
Quite a lot of the optimization ideas is borrowed from the new Vk
library -- such as "interning" the driver workaround strings to avoid
allocating their copies.
Needed a change in flextGL to allow merging in 3rd party gl.xml
additions because Chrome is apparently a center of the universe and thus
doesn't need to bother upstreaming its extensions, ffs.
Version query. Such a simple and obvious thing and because they forgot
to add such function to Vulkan 1.0, the only three possible ways to
retrieve a version retrieval function are:
1. with a static constructor that could make a library crash even before
main() is reached if the driver is *extra* shitty
2. with a init() function that would cause race conditions if ever
called from multiple threads (which of course can happen because you
need to know instance version in order to use the correct function
pointers and route pNext fields)
3. with a init() function that internally uses std::mutexes and
std::call_once and <functional> and atomics and whatnot and thus
takes longer to compile than the rest of the engine
Approach 2 chosen originally but the race condition countermeasures
turned out to be extra annoying to use, so switched to approach 1 now.
Vladimír Vondruš