* Add Drop file event support for android.
* Updated MIME type configuration and intent filter generation.
* "supportedMimeTypes" => "mimeType"
* `mimeType` -> `accept-file-intent`
The former was unclear about how the dependency would relate to web workers. Would it only be available to workers? Would it automatically spin up a worker?
`allow-web-workers` isn't 100% perfect, but it implies the correct answers to the questions above (no and no) and isn't too long.
It's designed to solve exactly this problem, and has been universally available since 2020.
The most likely scenario for `globalThis` to fail is if the user is stuck with an old browser, in which case `self` will be available. `window` will be too, but `self` also works in web workers.
Every single-threaded `ThreadPool` takes up a certain fraction of the app's time per frame. Without any coordination, they could take up more than 100% of the allotted time, causing the app to slow down. By using static variables, we can make them work together to limit the total time spent per frame.
* add createPerspective
I didn't find a createPerspective function so I tried to make one, but I don't really know if that will work.
* forgot something
* add doc
* I hope that's correct
added zero to one mode, and -one to one mode variants
* fix missing import
* I keep forgetting shit
* change to exceptions
* Update Matrix4.hx
* remove `new`
* remove period
* final changes
* Follow formatting conventions.
* Avoid using `Math.pow()`.
Haxe is unable to optimize this function away. Also, it seems to be unable to return numbers smaller than 1e-7, so that's what I used in its place. Smaller constants can work, you just can't get them from `Math.pow()`.
* Fill in missing entries.
As per all the other "create" functions.
* Use guard clause for better readability.
* Fix duplicate assignment.
* Make `createPerspective()` public.
---------
Co-authored-by: player-03 <player3.14@gmail.com>
Previously, null was propagated, which could lead to confusing errors from arithmetic operations. Now, it is ignored, and a warning is displayed that says where the invalid value can be found.
This is its only use case, so there's no need for an intermediate step of getting the library root. `haxelib path` does return the NDLL folder; the problem with the old implementation of `__findHaxelib()` was it got Lime's source folder instead.
We could fall back to `haxelib path` for very old versions of Haxelib, but most likely even people stuck on Haxe 3 have updated Haxelib.
Also, `haxelib path` gave incorrect results in the first place, so falling back wouldn't do any good.
This is where arm64 homebrew installs `libneko.dylib`. However, it may still be in `/usr/local/lib` if installed via the haxe .pkg installer, so we add both.
Previously, a compiled .app file for HL/C wouldn't launch at all because it couldn't find these libraries. For HL/JIT, it would launch, but it might crash later when it needed to load a missing library.
We need to bundle these dependencies into the .app file so that it can successfully launch on systems that don't have Homebrew installed, or haven't separately installed the exact set of Homebrew libraries that we need. We also don't want to have to make people ask their users to install Homebrew and to install the dependencies manually.
Tested the .app files for both HL/JIT and HL/C on a system without Homebrew. It failed before, but now it launches successfully!
