And properly account for -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR.
Module['canvas'] can be read even from code compiled with -s MODULARIZE
so it's a preferrable option to hardcoding it in Configuration. The
target strings in Emscripten depend on whether we're compiled with
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR (see
https://github.com/emscripten-core/emscripten/pull/7977). This is now
detected and handled at runtime to prepend element IDs with and use
the correct window and document magic targets.
Not yet sure about all interactions with older Emscripten versions and
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR set to 0, reverting until
it's clear.
This reverts commit c760acb548.
It doesn't really work for tests that depend on more than one plugin
(because there i would need to handle all combinations, somehow), but it
does the job when the end user has such use case.
Like, it's INEVITABLE to have a 100-line std::lerp() implementation for
questionable reasons but such dead-simple thing as std::pair doing moves
instead of copies where expected that should have been done CORRECTLY
back in 2011 still isn't working reliably across implementations?!
I guess I'm doing my Containers::Pair soon as well, then.
Those were initially implemented and documented when I thought glTF
uses a full cone angle, and I forgot to update them once I discovered
glTF has a half-angle. This is thus now consistent with glTF defaults
again.
Heh, I forgot to run the full test suite after the changes in
1eb1eec271 and then the CI accidentally
had all rendering tests skipped due to missing plugins (which got fixed
in the previous commit, d1ee0b7f7e), so
that didn't catch it either. Sigh.
And also test various potential false positives, which shouldn't be
detected as given format.
*Damn*, I need some utility class for printing this, this is
unsustainable.
Not that either way would be more correct than the other (this is what
three.js uses I think), but it was documented everywhere to be
1/(1 + d^2)
but the calculation instead did
1/(1 + d)^2
This now also means the analytical test equation works. I should have
paid more attention to it not matching before, because that obviously
pointed to this problem.
Point lights are now significantly brighter than before, the tests were
updated to use a larger distance to avoid issues with overflows. Does
not affect the (default) directional lights in any way.