x86_32 is not a commonly used architecture anymore, so it doesn't make much sense to include it by default anymore.
For reference, the Steam hardware survey no longer reports any 32-bit versions of Windows, macOS, or Linux. Windows 7 64-bit is currently 0.15% of Steam users, so presumably, 32-bit of any version of Windows is less than that. Windows 11 doesn't even have a 32-bit variant at all anymore.
We still build x86_32 on CI, to be sure that it will continue to work if someone wants to checkout Lime and build manually.
MAC_USE_CURRENT_SDK is an incredibly old relic from a very old version
of hxcpp (haxe 2 days). It was removed in:
9a7f7f931f
This is now instead controlled by the flag `MACOSX_DEPLOYMENT_TARGET`.
The setup command now only does two things:
- Sets up haxelibs
- Adds cli alias
34 is the minimum required version by Google Play, so it should be default.
Bumping to 34 and 35 requires updating both gradle-version and gradle-plugin-version.
The new versions now require an ndkVersion flag in build.gradle. This can be obtained by reading source.properties in the root of the NDK.
JDK 17 will be required for these updates. Previously required JDK 11.
While we add this permission by default, if a developer sets custom permissions, we want to avoid crashing when we try to access an API that we don't have permission to use
* Fix copyPixels crash on Hashlink
* Move nullcheck to C++
* Simplify further
* Avoid unneccessary object allocation
* Formatting
* Simplify by using an if statement
We're currently using freetype 2.9.1's algorithm for choosing font metrics, but it's not exactly the same as SWF (but it is closer than freetype 2.10's new algorithm).
This algorithm should more closely match the font metrics used by AS3 compilers when embedding fonts with [Embed] metadata in AS3.
This allows us to upgrade freetype beyond 2.9.1 (actually, 2.8.1 due to a bug in freetype 2.9) without wildly different font metrics. The reason that we don't want to change font metrics algorithms is that freetype's new algorithm is very different than the algorithm used for SWF fonts. The older freetype algorithm is closer to SWF, so we want to stick with it.
Thankfully, freetype supports accessing various metrics stored in font files in a more raw form, so we can provide our own custom algorithm in a way that is fully supported by freetype. I just copied the existing algorithm straight from 2.9.1 to restore our preferred behavior.
I confirmed that, after this change, OpenFL renders metrics like Lime 8.1.3. But we have the same upgraded freetype as Lime 8.2.0 that we had to revert for 8.2.1.
I plan to experiment with a mode that matches SWF even more closely, now that I have a better understanding of how fonts and freetype work.
::SOURCE_FILE:: must appear on the first line so that the .js.map line numbers match with our generated .js file line numbers
Added a comment to explain why that part of the file isn't formatted nicely with line breaks like the rest of the file.
This partially reverts bbcb8bea07
* Don't run `embedBytes()` if `embedByteArray()` is also running.
Both functions insert a constructor, and one class can't have two constructors, much less call `super()` with two different signatures.
I can only assume a bug in Haxe that prevented this from being an issue until now, and that Haxe 5 is fixing the bug.
* Check for `@:autoBuild` only after checking for embed data.
If we ever decide to handle the case of the embed functions being called for non-classes (meaning `getLocalClass()` would return null), we'd handle it in `embedData()`. Therefore `embedData()` should happen first.
The ios-deploy tool no longer works with new iOS SDKs that don't have DeveloperDiskImage.dmg, but Xcode added new commands that can be used in the terminal to install and launch on connected devices.
If a custom version is configured, users will think that just pressing enter will clear it, but it won't. It'll just keep the current value. To actually clear the value, they need to run lime config remove HL_PATH instead.
