Version query. Such a simple and obvious thing and because they forgot
to add such function to Vulkan 1.0, the only three possible ways to
retrieve a version retrieval function are:
1. with a static constructor that could make a library crash even before
main() is reached if the driver is *extra* shitty
2. with a init() function that would cause race conditions if ever
called from multiple threads (which of course can happen because you
need to know instance version in order to use the correct function
pointers and route pNext fields)
3. with a init() function that internally uses std::mutexes and
std::call_once and <functional> and atomics and whatnot and thus
takes longer to compile than the rest of the engine
Approach 2 chosen originally but the race condition countermeasures
turned out to be extra annoying to use, so switched to approach 1 now.
No need to use contractions, inverseRayDirection is okay because nobody
needs to type it anywhere. Also no need for the `ones` vector in the
test, Float/Vector3 works as well.
To make it convenient, the format equals to the usual file extension.
Currently skipping WGSL and DXIL however because I have no idea what
extension should they have, not even the DirectXShaderCompiler repo
tests show anything useful, there it's either generic LLVM *.ll or *.bc.
Come on, did people in 2020 also forget how to design file formats?!
It was originally done using the Deg() / Rad() constructors in order to
be compatible with GCC 4.6, but fortunately those days are long gone.
Co-authored-by: Squareys <squareys@googlemail.com>
By wrapping the module creation in a function that includes properties
from the original module as well as allowing to override the default
properties from the outside. This also means it's possible to create
differently named modules for multiple applications on the page.
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.