About time this got done. This also has an XFAIL for the case where a
distance field image is processed with an offset, have to fix the
underlying issue in TextureTools first.
Also added a range assertion for the distance field image setter to
match what the abstract base does, together with a corresponding getter.
The web isn't broken enough yet, apparently. Support for both of those
extensions was added in early 2020 (and I think I remember even seeing
them listed as supported in some browsers), one of them was renamed
mere two months later, one in January 2023.
And I discovered just by accident, the browsers *of course* don't even
bother advertising both to have some transition period. Or maybe that
transition period happened, for 3 weeks in January, and if some
developer didn't notice in that time, "it's their fault". Or maybe it's
my fault, for attempting to use an extension that was stuck in a "draft
status" for four years. THE WHOLE WEB IS EITHER IN A "DRAFT STATUS" OR
"DEPRECATED", THERE'S NOTHING IN BETWEEN, FFS!
Constant needless churn, UGH.
Those caused a warning to be printed to console during construction on
platforms without explicit uniform locations, and setting them with an
explicit location apparently causes a GL error on Qualcomm Adreno. They
*are* there in the input source, just DCE'd.
I won't argue whether that's a valid driver behavior or not. Just simply
not doing this anymore and silently skipping those uniforms instead.
There's still a TODO to actually support those properly, i.e. to be able
to change wireframe width or smoothness on a GS-less rendering. Then
they won't be DCE'd and this workaround wouldn't be needed anymore.
With the workarounds moved to the GL::Shader class itself, it's just a
complicated wrapper for adding the compatibility.glsl file and a rather
strange way to define a file-local helper for resource import on static
builds. Do that directly instead.
As this is now documented, it means 3rd party code can now directly make
use of these without having to reinvent the same logic, or worse,
rediscover the same driver bugs.
The compatibility.glsl file however stays private -- I don't expect
real-world projects needing *that much* diversity in their supported
GLSL versions, often the baseline is GLES 3.0 which makes a large part
of the file unnecessary, and the projects might choose to for example
always have implicitly queried uniform locations to not have to
maintain two code paths.
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.
Same as in Corrade, they still default to static because that's the
least painful.
Plugins however still need to be forced to be built static on platforms
where the PluginManager doesn't have any support for dynamic plugins
implemented. The logic is now only simplified, to not have to change it
again when e.g. Android gets the needed bits implemented in
PluginManager.
Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
Optionally, because the TestSuite-related APIs such as CompareImage
aren't even built if the TestSuite library isn't built. Is a bit
brittle, but I don't feel like adding some kind of internal option to
configure.h just for this alone.
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.
Vladimír Vondruš