The new version no longer checks the return code of `SDL_GetWindowOpacity`, for consistency with the other getters. In theory this should be fine, because the only documented error condition is if the window is invalid, at which point none of the getters matter. If the platform doesn't support transparency, "opacity will be reported as 1.0f without error."
...Unfortunately, after a little bit of testing and a lot more thought and consideration, I've realized there really isn't a way to do this without doubling the allocation. Ouch.
Followup to these two commits:
02617a854dad3a632927
In the second commit, the buildBuffer call in HTTPRequest was
found to conflict with the way local requests are made, with the
bytes being set directly. So buildBuffer was moved to NativeHTTPRequest
instead. Upon promise completion, now, the value of bytes should always
be correct, and buildBuffer need not be called.
But buildBuffer is called again in NativeHTTPRequest.loadText. For local
requests, this will lead to the same problem that the second commit
fixed (presumably), and for network requests, this leads to the nulled
out buffer being accessed a second time, resulting in a crash.
So since the received value of bytes is already correct and buildBuffer
is harmful, the buildBuffer call is removed from loadText.
Both local and network requests are happy now!
The HashLink executable expects hlboot.dat and libraries to be in the current working directory (it's not enough for them to be in the same directory as the executable). Make the .app file launch a shell script that 1) changes the current working directory 2) launches the HashLink executable
The sourcePlay call in NativeAudioSource.play is removed, since
setCurrentTime will always do that itself. Additionally, within
setCurrentTime, sourcePlay was happening before setting the byte
offset for non-streamed sounds.
This appears to fix the problem of sounds playing the first part
multiple times, described here:
https://community.openfl.org/t/sounds-play-twice-on-ios/12163
This change places the focus on the one known use case, while clearing
up potential confusion caused by similar-sounding classes that function
totally differently.
