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.
The glDepthRangedNV() and glClearDepthdNV() behave differently from
glDepthRange() and glClearDepth() -- they don't clamp. There doesn't
seem to be any change in recent GL related to this, so this extension is
still valuable for improving depth buffer precision. Or, alternatively,
it's possible to use the glClipControl() API from GL 4.5 to achieve the
same.
I need alpha to coverage for rendering line caps with MSAA, took it as
an opportunity to expose the other related features as well. Fun how I
survived 12+ years without needing those.
Instead of having them wrapped in extra functions for
extension-dependent functionality. The only case that stays is the line
width range implementation, as the raw variant looked too ugly /
dangerous otherwise.
Every time I push an innocent change it ends up breaking the
non-deprecated build, such as 34a91cf458.
Sigh, I really need to clean up the backwards compatibility ifdefs...
"Funny" how this is the only API where I can't use glCreateTextures().
Like, it would have been so easy to just stop teaching glGen*() and
all their quirks and "this ID exists but it's not an object until you
bind it somewhere actually" to people altogether, BUT NO! FFS.
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.
THe remaining elements are zero-filled, consistently with the behavior
with zeroing out attributes that are missing in subsequent meshes. One
use case is concatenating a mesh with 4 JointIds / Weights into a mesh
that has 8 instead.
Right now, copying larger arrays to smaller arrays is still disallowed
to avoid data loss. That is inconsistent with behavior for attributes
(which are silently left out when not present in the first mesh), I'll
need to think about this more and solve the inconsistency somehow.
Either by allowing array slicing or by failing for unhandled attributes
as well, and the latter makes more sense from the perspective of
avoiding data loss.
And use static functions with an explicit "self" pointer instead. Those
have half the size (8 vs 16 bytes on 64bit x86), which in turn reduces
the state tracker memory use by about 750 bytes. On desktop GL with an
Intel GPU & Mesa this reduces the state tracker allocation size by almot
10%, from 8.3 kB to 7.6 kB. Not bad.
Apart from small memory savings, this also removes the need to include
the full class definiton from the State headers on MSVC (because
on that compiler the member function pointer size is different based on
whether the type definition is known or not, IMAGINE THAT BEING A
FEATURE AND NOT A BUG), leading to less header dependencies and better
incremental compile times there.
This was already done in some cases (and the Vk library used this from
the beginning), and as I'm about to add some more extension-dependent
functionality it felt like a good time to finish that change, finally.
In some cases the *Implementation() could even be dropped in favor of
pointing to the GL API directly (such as is already done for various
glUniform*() calls), that'd be another step -- this is good enough for
now.
Every time I think all std::initializer_list APIs already have an
ArrayView counterpart I discover a new one. (And yes, I did this for
Framebuffer, only to later realize that DefaultFramebuffer suffers from
the same.)
It was needed in the times before StringView, where the setLabel() APIs
had overloads taking a const char(&)[size] to avoid allocating a
std::string. But that got all removed and cleaned up in
bc884428f8 (two years ago!), yet somehow I
forgot to remove these includes as well.
In some cases the ArrayView was still used inside the header for
delegating from std::initializer_list overloads. Those are now
deinlined to not need the include anymore. The only remaining place that
*needs* an ArrayView include is Buffer.h, where it accepts an
initializer_list<T>. But there it's fine I think, the class is dealing
with memory as well.
Merging two sorted sequences is is something I always struggle with to
write from scratch. Fortunately here I could just reuse what got done for
DebugTools::CompareMaterial already, haha.
Such an unnecessary footgun -- I was already checking the other case,
having attribute data too short, but this I thought is fine because it's
not leading to any crash. Well it's leading to needless pain and
suffering, that's what it is doing!
And of course already found FIVE such bugs in just Magnum tests alone.
Okay, GCC 12, this warning about an uninitialized member was actually
helpful, thank you. Too bad I didn't see it in all the useless
warning noise that you also produce.
Having code snippets in docs compiled and checked for syntax and
outdated API errors is great. In theory. In practice the people reading
docs have NO IDEA how much needless suffering goes into making the
compiler collaborate with me on such a seemingly simple task. UGH.
Say how many devices there were in total, so it's possible to
distinguish the case of trying to find a CUDA device on a machine with
no NVidia GPU (where it says it found some other EGL devices) and the
case of drivers being completely broken for some reason (where it says
it didn't find any device at all).
Uses StridedBitArrayView underneath. Waited for this container to exist,
because implementing this using bools and wasting 8x more memory wasn't
a good option. Plus, being able to address single bits opens a
possibility to describe individual bits in enum flags, whereas the only
other option would be to take the whole flag as an opaque type
containing "some bit values".
Vladimír Vondruš