SDL3 Support #1915
SDL3 Support #1915
Conversation
|
the thing is sdl module needs to switched with sdl3 and vulkan implementation needed in lime and SDL android java codes needs to be updated too |
I did update the module to SDL3. |
I meant to say SDL2 needs to be removed from the lime and fully switched with SDL3 |
It does not? I don't see why SDL2 shouldn't be an option. |
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.
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.
Fix utf8 conversions in hb_buffer_add_utf8
…to ios-deploy Devices running iOS 16 and older don't support xcrun devicectl, but they should still work with ios-deploy.
…ble (paired) and wired (closes openfl#1918) Consolidate fallback to ios-deploy when Xcode version < 16 and when xcrun devicectl doesn't find any devices
cl : Command line warning D9002 : ignoring unknown option '-std=c11'
…un devicectl includes iPadOS, so there's no need to check for that one separately
|
Interesting that the proposal is to have both available Maybe the SDL2 can be available, and used by default, and deprecated later as Lime's SDL3 implementation is proven to be stable. |
It was mostly because mojoAL doesn't have a SDL3 version yet, and from what I was reading on the build files it's used for Audio on the Switch |
|
It'a also used instead of OpenAL Soft when static linking (due to licensing conflicts) I believe |
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.
The array size is already determined by the first loop
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.
…loop Fix Font.getGlyphs returning zeros and looping
|
That was a lot of work, wew |
There was a problem hiding this comment.
We have been reviewing this pull request internally and have found no major issues so far, only a couple missing graphics (which should be trivially resolved on our end). Performance seems similar and it would be great to have the new features introduced once this is merged.
Good to know! About missing graphics, I've had a few FileIO issues, but I thought I had (finally) fully fixed them, could you elaborate one what you mean? I just wanna make sure I didn't break something |
|
Theres only one function in this PR that I needed to get, which was SDL_GetTicksNS(), which is similar to the function being exposed as "System::GetTimer();" I implemented this as "System::GetTimerNS();" but I am wondering of other SDL3 only features have yet to be exposed? Otherwise this PR looks good :D |
After more testing I found that the missing graphic was related to how I was handling SDL timestamps, and resolving the issue fixed the graphic. There are no FileIO issues that I am aware of. |
Oh yeah definitely, I at the very least want to
I also know SDL3 adds a camera API who would allow us to implement Camera support, same thing with the System Tray API. The only thing currently exposed is that enabling high DPI should also work on windows now, the above is only my wishlist/to work on list after this one gets merged. If you wanna see everything SDL3 adds this is a pretty good list, though I noticed it doesn't mention some things like SDL_WINDOW_TRANSPARENT |
We've asked Fancy to wait on exposing any of SDL3's new features. To be clear, we definitely plan to take advantage of many of those new features in Lime and OpenFL because there are a lot of very nice things in SDL3. However, in terms of testing and review, it's much easier if we can focus on the upgrade with the same set of features that already existed in SDL2. After we merge this foundational SDL3 support, then we can start having fun with the new stuff. |
Awesome! Can't wait :D |
|
It will also be great to start seeing changes in OpenFL as well, such as replacing this line with the proper nanosecond timestamp call: (i.e. finally resolving #1569 ) |
That line only affects the flash target... and does not actually solve anything. We also can't use anything from our native libraries in flash at all. WIth that said, the main loop has been overhauled for exact preciseness with better support for vsync (and fallback for hardware that doesnt support vsync). Most of that work is about 95% complete and should make it's way into 8.3 over the coming months. |
|
I tried this on Android and image files (PNG atleast) decoding seems to have broke? I did some logging and ended up with the assumption that the |
|
Also forgot to mention that trying to get displayMode is throwing a segfault for me on Android |
I know it isn't because this whole PR was made on Linux... Very weird Android is broken |
|
Just chiming in. |
Yay this is really important. I'm glad you chimed in I was just wondering how well this worked on Pi. |
Current work to get Lime working on SDL3
Fixes: #1848