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.
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
openal-soft assumes that aligned_alloc is available with c++17. Newer
android ndks set c++17 by default, however they do not expose
aligned_alloc without setting min sdk version to 28.
We can avoid this issue by forcing openal to be compiled with c++11.
Also note, we have HXCPP_CPP11 defined, however, hxcpp ignores this for
the android toolchain. This means we must set it explicitly
See:
f5e0eef34d/common/almalloc.cpp (L15)
Hxcpp doesn't respect HXCPP_CPP11 for android. We can avoid this issue just by adding -std=c++11 here. This resolves a conflict with openal soft 1.20.1 for android builds. This works because the library assumes c++17 and invokes a function that isn't available in android sdk below 28.
If the text is invalid, then readNextChar returns -1 and does not
progress to the next character. This previously meant that we got stuck
and looped indefinitely.
Previously, the first for loop would reach the end of the characters, so
no further characters were read in the second loop. This meant that the
array remained filled with 0 values.
This function wants the utf8 length, but text->length does not give
this. We can instead use -1 to tell harfbuzz to treat it as null-
terminating, which is the case with all hashlink strings anyway.
A HxString is not guaranteed to be utf8 on hxcpp, so we need to use
hxs_utf8 to convert it otherwise it incorrectly displays any utf16
encoded string.
Unfortunately, hxs_utf8 doesn't give us the length of the utf8 string.
The best thing we can do is to tell harfbuzz it is null terminated. This
isn't perfect because technically hxcpp strings are allowed to contain
NULL, but it's better than all utf16 strings being broken.
Hxcpp's mbedtls has MBEDTLS_NET_C disabled, which meant that older
versions of curl which use this feature cannot be linked against it.
This version of curl no longer requires this feature, which avoids the
issue.
Hxcpp 4.3.0 has an mbedtls_config.h file in ${HXCPP}/src/hx/libs/ssl,
which we have to ensure is included, but older versions do not.
To support both 4.3.0 and older versions, we can add an empty
mbedtls_config.h and add the include path at the end. This way it will
only be used if it does not exist in the previous include paths.
* 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.
