The KTX and glTF plugins now print a commit identifier in their
generator string for better tool trackability, have to disable that to
have predictable output.
The DDS plugin now Y-flips compressed pixel formats, leading to a
different message. Disabling the flip to not have to deal with any
message at all.
It should be returning twice the value, this is the half-angle. Sad that
this went unnoticed for so long, extra bad points for me to have a
complicated test but not actually verifying that the returned value
makes sense, sigh.
A *nasty* option would be to just fix it, but -- even though there's a
chance nonbody ever used it since nobody ever complained -- it would
introduce breakages to any code that fixed it and that's something to
definitely not do in a trusted codebase. So it's instead deprecated,
firing an annoying warning to whoever might have called it, and there's
a (temporary) replacement called halfAngle() that does exactly the same
but is named appropriately.
Then, once the deprecated angle() is removed (the usual deprecation
period, so a year or the span of two releases, whichever takes longer)
and enough time passes (so another year at least), I'll reintroduce it
with a correct return value.
Interesting, didn't know this kind of feature support was possible. I
guess it's still better than no GLES3.2 at all. Also, it's a phone from
2017, so probably not all that important to care about anymore anyway.
There are two variants per angle type, so a total of four entries.
I used the same exact values for the multipliers as the ones in
Magnum::Math (utilizing Math::Constants<T>::pi()).
Added Float & Double overrides, so the other variants (Half & integer
variants) are effectively untouched.
Added Dot() & IsNormalized() intrinsic functions for each entry.
The reason we need separate entries for Float & Double is because the
epsilon values used for Dot() are different.
Epsilon values are taken directly from Magnum::Math::TypeTraits & they
are added to & subtracted from 1.0, in order to avoid using abs(), which
is prohibited in .natvis.
Same as the corresponding Corrade change. Should make
MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS working also in cases where Magnum is
linked to just DLLs but not the main application executable. Such as
various plugins or native Python modules.
It isn't a nice UX to force users to hardcode a DLL name of their own
application when building a *dependency library*, but is a simple enough
middle ground between global symbol deduplication not working at all and
having to loop through all possible DLLs with EnumProcessModules() until
a symbol is found.
While extremely easy to do with the linear lookup, I bet it'd be
something utterly complex like trying to hash a std::pair with the
original hashmap-based implementation.
Let's guess what would be faster -- making a ton of tiny allocations,
hashing a bunch of numbers in a very complex way and then jumping
through all those indirections and cache misses of a multimap linked
list for each and every attribute of each mesh, OR going linearly
through a two tiny arrays for every mesh? I don't have any benchmarks
ready but I bet the latter will win.
Back when I wrote the test I didn't know what would be the most
convenient way to use the API yet, so it was unnecessarily verbose in
various places. Now I do.
Also using Utility::copy() to populate the arrays. No need to suffer
this much for no reason.
The second lookup was only needed for a type compatibility assertion,
which is a bit unfortunate. It wouldn't be a problem on a no-assert
build, but for various reasons people shouldn't be using these. Too
dangerous.