This allows us to get rid of the StaticArrayView, which is the last
roadblock on the way to a single-header math. The planes() are now
deprecated, along with the include, and will get removed in a future
release.
The one from std:: needs to #include <algorithm> to be used portably.
That's insane, so it's a big nope. Also, the standard implementation
takes the value always by reference, making it unnecessarily slow for
small types. We do better here.
Pros:
* faster compile times (#include <tuple> is 13k lines, ugh)
* ability to have NoInit and ZeroInit constructors
* ability to do fuzzy compare
* named members, so we don't have to use mutable std::tie()
Cons:
* ... none?
The old Color[34]::Hsv is still a tuple and the new ColorHsv is
convertible to/from it (and even std::tie() works). These are all
deprecated (along with the <tuple> include).
Not sure what I thought here, but using GL_IMPLEMENTATION_COLOR_READ_*
with glGetFramebufferParameteriv() is possible only since GL 4.5
(there's no extension adding it) and there's no equivalent for it in
GLES 3.1. I assumed that since the entry point is defined in 3.1 then it
would also accept the same enum, but apparently not -- and this
inconsistency is not fixed in 3.2 either.
Funnily enough, all drivers I tried (Mesa ES, SwiftShader, ANGLE) were
accepting this. The first driver that complained was ARM Mali on Huawei
P10 and there I assumed a driver bug -- but on the contrary, this is the
only driver following the spec properly :)
Now the glGetFramebufferParameteriv() API (and the DSA equivalent) is
used only on GL 4.5 contexts and up, everywhere else it's done using
the old-style glGetInteger(). I also renamed the implementations to not
misleadingly mention ES 3.1, since it has nothing to do with this. The
code path dispatch code is a bit entangled due to all the workarounds,
hopefully not breaking any behavior that worked before.
Interesting that I didn't run into this until testing on Mesa AMD
drivers. So far it worked for NV, Mesa Intel, Intel Windows, Android and
many more. Heh. Also improved the test to actually verify the user
pointer gets passed through correctly and updated the docs to reflect
this behavior.
Would fail on an incomplete framebuffer error on framebuffer-less
windowless contexts. Didn't happen before, I think it's because of a new
check in a new Mesa.