This reverts commit 6bb0179c65 from 2018,
which in turn reverted commit f6ba4111e1,
which in turn reverted commit 4ce2875262
from 2015. The related Emscripten PR was merged in 2018, so it's safe to
assume everything works as expected nowadays.
Which also means I can finally delete my Emscripten fork that contained
the original branch that attempted to add glDrawRangeElements() in May
2015, before WebGL 2 was even supported in Emscripten, or Firefox.
This makes the minimal supported Emscripten version 1.39.5. With some
more effort this could be changed to 1.38.27, but I don't think anybody
needs that.
AsciiToString is not included by default on 3.1.21+ and including it is
basically impossible on the library side because I don't think they
fixed the case of supplying multiple DEFAULT_LIBRARY_FUNCS_TO_INCLUDE
options on the command line in order to concatenate those lists yet.
Also, given that UTF8ToString is probably already used in other places
since it's included by default, using AsciiToString would only mean
inflating the JS code.
So far this was only possible by creating a temporary MeshView, while
everything else (index/vertex count, base vertex, base instance, ...)
was changeable directly on the Mesh.
Could make sense to eventually turn those into --magnum-whatever options
and have them available always. There's however the yet-unanswered
question of how to provide help for those if a GL/Vk context has its own
set of options, and how to make them not warn about mutually invalid
options.
Such as Emscripten or Android. The hypothetical use case is converting
shader files directly on an Android device to debug things, or having a
Node.js build of a scene/image converter for "portability".
Static plugins can be linked to these if Magnum is built together with
Magnum Plugins in a CMake superproject and the plugins are then linked
via the MAGNUM_*CONVERTER_STATIC_PLUGINS CMake variable.
The fontconverter and distanceconverter tools cause a CMake error on
Emscripten as it's not currently possible to access the GPU through a
command-line Node.js app. On Android they work though.
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.
Vladimír Vondruš