As far as I can tell, SDL_QuitSubSystem is not required, and SDL_Quit should automatically quit each subsystem. However, this stops the crash, so maybe there's some kind of race condition that this avoids.
Hxcpp needs the PLATFORM define for older ndks that require the gcc toolchain. We initially removed it since Lime potentially was going to have a minimum requirement of android sdk 28 due to openal soft version 1.20.1, however, this was solved by upgrading to 1.21.1 which presented no further conflicts with sdk 21.
To simply things, we just provide both defines for now.
Co-authored-by: player-03 <player3.14@gmail.com>
They were using float values, but they should have been int values instead.
The numeric type conversion was causing some kind of data loss that resulted in wrong values being returned in some cases. In particular, arrow keys.
* Add SDL rumble
* Fix rumble
* whitespace fixins real (#2)
* whitespacing real.. please!
* nativecffi rumble thing fix lol
* Remove trailing whitespace.
* Use SDL's argument names and order.
* Standardize formatting.
* Make `SDLGamepad` fully static again, for simplicity.
Also, consistently use `find()` instead of array access, to avoid accidentally creating entries.
Also also, consistently use guard clauses instead of indenting.
* Make another guard clause.
* Update CFFI function signature.
* Use `clamp()` instead of `if` statements.
* Include required header for `std::clamp()`.
* Revert "Use `clamp()` instead of `if` statements."
`std::clamp()` was not available until C++17, and we'd like to continue supporting older versions.
This reverts commit 715a270f79.
* Revert "Include required header for `std::clamp()`."
This reverts commit f47aebf640.
* Tidy up.
* Document `Gamepad.rumble()`'s arguments.
* Don't limit rumble duration.
SDL apparently supports the full Uint32 range, so there's no reason for Lime to restrict it.
* Fix whitespace.
* Add rumble support in HTML5 (experimental).
---------
Co-authored-by: Cameron Taylor <cameron.taylor.ninja@gmail.com>
Co-authored-by: player-03 <player3.14@gmail.com>
* allow setting gradle jvmargs in project.xml
* Make gradle.properties fully configurable from project.xml.
---------
Co-authored-by: Joseph Cloutier <player3.14@gmail.com>
Documented semver-based versioning flow
- Explained usage of patch (develop), minor (x.x.x-dev), and major (x.0.0-dev) branches
- Added guidance on where to submit bug fixes, new features, and breaking changes
- Improves contributor clarity and aligns with current project workflow (e.g., Lime 8.2.2 -> 8.3.0-dev, 9.0.0-dev)
This helps reduce confusion about where to submit changes and ensures consistency across releases.
For non windows platforms, we previously just passed char* into wstring,
which didn't perform the necessary conversion into utf32 which is
expected when hxcpp converts a wchar string to a hxstring on platforms
where wchar has 4 bytes.
If HOME is NULL, we cannot return here immediately, since we haven't
called `System::GCExitBlocking()`. This currently causes:
```
Critical Error: Allocating from a GC-free thread
```
This is already handled correctly for `USER` and `DOCUMENTS`, however
`DESKTOP` was missed out in f6e38208d3
Followup to 6f2f88ca74
Now checks for devices with filters in the following order of preference:
1. State == 'connected' AND transportType == 'wired'
2. State == 'connected' AND transportType == 'localNetwork'
3. State == 'available (paired)' AND transportType == 'wired'
3. State == 'available (paired)' AND transportType == 'localNetwork'
Also adds developerModeStatus == 'enabled' filter as a requirement for all checks.
If the app is meant to be iPhone-only or iPad-only, adds the appropriate filter for that too.
I assume we used `untyped __js__` to get around incomplete externs, but Haxe 3.2 updated the externs, and they've included the second argument ever since.
Haxe 5 defaults to 1.15, but we're currently still bundling an older version. So we need to specify hl-ver or it won't work properly because Haxe 5 will produce code that older HashLink isn't compatible with.
If hl-ver is already specified, or if a custom HL_PATH is defined, does not set hl-ver because that may be undesirable.
Tested on macOS, Linux, and Windows. Works better with Haxe 5 than HashLink 1.12 did. This upgrade is easier than 1.14 and presumably 1.15, which we can still do later.
* Store the job's thread in `JobData`.
Since we're storing more and more in `JobData`, and the background thread only needs three bits of that data, I added those to `ThreadEvent` so we don't have to pass the full object. This may improve performance in HTML5 specifically, where passing a class instance incurs an overhead.
* Allow a single `ThreadPool` to run jobs in both modes.
* Remove unnecessary `@:forward.new`.
* Improve check for whether to call `Thread.returnMessage()`.
Now that thread pools can manage both types of job at once, we can't rely on `mode` to determine whether we're on a background thread. Honestly, I shouldn't have relied on it in the first place.
* Improve `ThreadPool.isMainThread()`.
No need to set `__mainThread` based on `isWorker()` when `isWorker()` already gives the information we're after.
* Correct and clarify documentation.
* Start new jobs immediately when a slot opens up.
For single-threaded jobs, this means a pool can now handle multiple per frame. For multi-threaded jobs, this only slightly reduces the delay between jobs.
* Fix missing function call.
* Add missing import.
Forgot this when overriding the "send" functions.
* Simplify comment.
It's a private variable, so all it really needs to do is mention the location it gets used.
* Don't count the main thread in `currentThreads`.
Plus, alphabetize the variables.
In 8.2.0, a single-threaded pool would report `currentThreads == 1` when running a job, meaning it counted the main thread. But in retrospect, this was both redundant (with `activeJobs`) and unexpected, so I'm counting it as a bug.
* Update documentation.
* Remove redundant check.
All the jobs in `__multiThreadedJobs` are already known to be running in multi-threaded mode. This is left over from when pools were locked to a single mode.
* Handle error case differently.
We still need to throw an error when `mode` is `MULTI_THREADED`, but this can now vary per job, so the check must happen during `run()`.
Also, the old error message was out of date. You can't pass a function to the `ThreadPool` constructor.
* Remove unnecessary `#if`s.
On other targets, it will return `true`, which will be inlined and optimized out. The conditional compilation just added clutter.
* Rewrite `ThreadPool` to use `Deque` on native targets.
Using the flag `lime_threads_deque` to distinguish between this and the old approach. Hopefully someday we can remove this flag, once we implement something akin to `Deque` in HTML5.
That aside, the hardest part is keeping track of the state of each thread. That's why there's so much more complexity: whenever the main thread sends a message to a worker, it needs to wait for confirmation, but also not send any more messages while waiting. And the code that tracks all this needs to work in both modes (with and without `Deque`).
* Bug fix: `firstLoop = false` can get skipped.
* Fix misplaced `#if`.
* Add missing `#if`.
* Make sure all events are received before removing the update listener.
After all jobs are done, threads will send `EXIT` events. These must be processed before removing `__update`, otherwise they'll linger in the queue until the next job starts.
* Keep better track of how many threads are idle.
Previously, while a thread was exiting, `ThreadPool` could think it was still idle. This would cause it not to spin up a new thread for the next job, leading to a pending job with no threads available to handle it.
* Remove redundant code.
* Fix null pointer error.
* Fix bugs in `cancel()` and `cancelJob()`.
* Don't shut down a `ThreadPool` while work events are queued.
Co-authored-by: Barış Yıldırım <25794892+barisyild@users.noreply.github.com>
* Add missing `#if`.
---------
Co-authored-by: Barış Yıldırım <25794892+barisyild@users.noreply.github.com>
