Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge '8.2.0 dev' #1810

Merged
merged 61 commits into from
Jul 4, 2024
Merged

Merge '8.2.0 dev' #1810

merged 61 commits into from
Jul 4, 2024

Conversation

Dimensionscape
Copy link
Member

No description provided.

barisyild and others added 30 commits March 16, 2024 03:40
This seems to be required with Xcode 15, but was not required previously
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.
…e name.

This is required but not obvious, so we should spell it out.
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 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.
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.
More work may need to be done to transfer an image from a worker to the main thread, but this will at least prevent crashes.
Make `Matrix3` an abstract over Float32Array (just like `Matrix4`)
Fix error when locating Lime's bundled NDLLs.
* 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 <[email protected]>
Whitespace changes interfere with merges, so this change must be applied manually first.
… better than new Process()

new Process() was crashing before the process could start for some reason
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.
Create a placeholder object to send `Matrix3`s to C++ code.
joshtynjala and others added 29 commits May 30, 2024 16:02
…) (references #1778) (references #1792)

Fixes gradient drawing in OpenFL
Make `Matrix3` use column-major order.
…nfigurable

make preserveDrawingBuffer configurable
Automatically delete stale assets and dependency files.
This was mistakenly removed while merging.
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.
…ble paths from Android SDK

The 'SDK Tools' package located in /tools/ is officially considered 'obsolete', so we should not use it by default.

We now prefer /platform-tools/adb over /tools/adb

We now prefer /emulator/emulator over /tools/emulator

If the newer replacement executables are missing, we still try to fall back to /tools/. This should allow older Android SDKs to continue to work properly.

Additionally, if neither version can be found, we report an error. For adb, we always need it, so we always report an error if it is missing. For emulator, we report an error only if we're actually going to use an emulator.

/tools/android doesn't have a newer alternative. We were running 'android list avds' to get a list of all available AVDs. However, both '/emulator/emulator -list-avds' and '/tools/emulator -list-avds' provide a simple list of AVDs separated by line breaks. So it seems that we never actually needed /tools/android. Plus, it outputs a better format that doesn't require searching every line of the output string for 'Name:', and we can just split and trim. So I completely removed /tools/android and we now use either '/emulator/emulator -list-avds' or '/tools/emulator -list-avds'.
… when they are used only, instead of immediately in AndroidHelper.initialize()

It turns out that adb isn't included GitHub Actions unless you install it specifically. However, you can technically build Android apps with Lime without adb, so we shouldn't report the error in initialize(). Most important is install(), where both adb and emulator are commonly used.

Followup to eed47e7
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.
* Add Drop file event support for android.

* Updated MIME type configuration and intent filter generation.

* "supportedMimeTypes" => "mimeType"

* `mimeType` -> `accept-file-intent`
…nifest.xml

Replace (project.window.fullscreen ? ".Fullscreen" : null) with (project.window.fullscreen ? ".Fullscreen" : "")
…brew/lib to rpath of lime.ndll

Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.

I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.

As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
@Dimensionscape Dimensionscape merged commit e1457e7 into feature/System-block-usleep Jul 4, 2024
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants