This is also the first time they just stopped bothering and introduced a
name that is neither in the official gl.xml nor in the
google-private ANGLE-specific gl.xml. So yeah, gotta make my own gl.xml.
I wonder how other people do this. Do they just type out the headers
themselves? Or what's the process for this fucking trash fire these
days??
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.
On desktop this saves about 50 kB in symbols. Was done for Vulkan
already, this follows that (two years later). I need this in order to
solve the problem of static globals being unique across shared libs, and
it sounded better to export just one symbol instead of 689.
ARB_sample_locations and AMD_shader_explicit_vertex_parameter /
NV_fragment_shader_barycentric for barycentic coords in the vertex
shader. The ARB extension mentions GLES but doesn't have any assigned
number, so I'm treating it as desktop-only. There's a NV variant that
does have an ES extension number, but I don't really want to add it just
because that.
Vladimír Vondruš