SDL3 Support

[Fancy2209]

Current work to get Lime working on SDL3

Fixes: #1848

[ghost]

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

[Fancy2209]

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.
SDL still supports OpenGL, no need for Vulkan.
I will update Android Java when I get this working on desktoo

[ghost]

I did update the module to SDL3.

I meant to say SDL2 needs to be removed from the lime and fully switched with SDL3

[Fancy2209]

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.

[EliteMasterEric]

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.

[Fancy2209]

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

[ACrazyTown]

It'a also used instead of OpenAL Soft when static linking (due to licensing conflicts) I believe

[Fancy2209]

I accidentally pulled develop into tbe branch, not sure what to do about that.

[Fancy2209]

That was a lot of work, wew
Finally all targets pass Ci and now this is ready for proper reviewing and better testing

[EliteMasterEric]

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.

[Fancy2209]

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

[Kade-github]

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

[EliteMasterEric]

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

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.

[Fancy2209]

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

Oh yeah definitely, I at the very least want to

• expose SDL_GetTicksNS like y'all did on Funkin
• Allow Windows to optionally support for transparent backgrounds (I already figured this one out just waiting on this to get merged before PRing it)
• replace file dialogs with the SDL Dialog API when using SDL3
• Expose SDL_GetSystemTheme

I also know SDL3 adds a camera API who would allow us to implement Camera support, same thing with the System Tray API.
I also need to check what we need to change for Clipboard to handle the fact it can get more than just text now.

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
https://wiki.libsdl.org/SDL3/NewFeatures

[joshtynjala]

I am wondering of other SDL3 only features have yet to be exposed

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.

[Kade-github]

I am wondering of other SDL3 only features have yet to be exposed

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.

Awesome! Can't wait :D

[EliteMasterEric]

It will also be great to start seeing changes in OpenFL as well, such as replacing this line with the proper nanosecond timestamp call:

https://github.com/openfl/openfl/blob/782627b89de76ff6ca85c267f8e36e2e09e1dc92/src/openfl/display/FPS.hx#L54

(i.e. finally resolving #1569 )

[dimensionscape]

It will also be great to start seeing changes in OpenFL as well, such as replacing this line with the proper nanosecond timestamp call:

https://github.com/openfl/openfl/blob/782627b89de76ff6ca85c267f8e36e2e09e1dc92/src/openfl/display/FPS.hx#L54

(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.

[KarimAkra]

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 lime::fread method on SDLSystem isn't working properly (although it's literally the same thing in SDL3 migration docs... could be an internal issue with SDL..? Tho i found nothing on SDL issues)
I might be wrong but if that is the source of the issue then any C++ target other than Windows should have Image decoding issues and anything that uses lime::fread would be broken on these platforms

[KarimAkra]

Also forgot to mention that trying to get displayMode is throwing a segfault for me on Android

[Fancy2209]

Tho i found nothing on SDL issues) I might be wrong but if that is the source of the issue then any C++ target other than Windows should have Image decoding issues and anything that uses lime::fread would be broken on these platforms

I know it isn't because this whole PR was made on Linux... Very weird Android is broken

[gepatto]

Just chiming in.
I've tested on a Raspberry Pi.
And it works with some adjustments to the build.xml
I have been working with a default sdl3-config file that one gets when compiling sdl3 with default settings.
It's a bit different from custom linux sdl3 config in this lime branch so I'm using a separate file for the Raspberry Pi.

[dimensionscape]

Just chiming in. I've tested on a Raspberry Pi. And it works with some adjustments to the build.xml I have been working with a default sdl3-config file that one gets when compiling sdl3 with default settings. It's a bit different from custom linux sdl3 config in this lime branch so I'm using a separate file for the Raspberry Pi.

Yay this is really important. I'm glad you chimed in I was just wondering how well this worked on Pi.

[Fancy2209]

I will close this PR and re open a version with a cleaner tree soon, will also take the time to try to wire mojoAL as it now supports SDL3

[joshtynjala]

Today, I took some time to check out this branch, merge in the latest from 9.0.0-dev, and do a little local testing.

The Feathers UI components-explorer sample builds and runs with neko, hl, and cpp targets on macOS. However, rendering on my HiDPI monitor is not quite right when I use<window allow-high-dpi="true"/>. Everything renders at the correct scale factor, but it's like the stage bounds reach beyond the window on all four sides. I suspect that this is related to the way that coordinates have changed in SDL3 to better support HiDPI.

For iOS, it builds and launches. However, I'm seeing only a white screen when I launch components-explorer. I haven't investigated deeper than that.

For Android, it builds, launches, but renders everything at a super tiny scale factor. Probably a similar scaling issue with SDL3's changes to coordinates for HiDPI.

I'm planning to test on Windows and Linux later, but these are my initial observations on my main machine.

[Fancy2209]

Today, I took some time to check out this branch, merge in the latest from 9.0.0-dev, and do a little local testing.

The Feathers UI components-explorer sample builds and runs with neko, hl, and cpp targets on macOS. However, rendering on my HiDPI monitor is not quite right when I use<window allow-high-dpi="true"/>. Everything renders at the correct scale factor, but it's like the stage bounds reach beyond the window on all four sides. I suspect that this is related to the way that coordinates have changed in SDL3 to better support HiDPI.

For iOS, it builds and launches. However, I'm seeing only a white screen when I launch components-explorer. I haven't investigated deeper than that.

For Android, it builds, launches, but renders everything at a super tiny scale factor. Probably a similar scaling issue with SDL3's changes to coordinates for HiDPI.

I'm planning to test on Windows and Linux later, but these are my initial observations on my main machine.

That sounds like me using SDL_GetWindowSize() instead of SDL_GL_GetDrawableSize() somewhere

[joshtynjala]

And I tested Windows and Linux this afternoon. I got sidetracked for a bit because I needed to upgrade from Visual Studio Community 2019 to 2022 to get SDL3 to compile on Windows. I was getting the following error:

Cannot open include file: 'gameinput.h': No such file or directory

Upgrading to VS 2022 fixed it, for some reason. That's fine. I'm glad I'm not on an ancient version of VS anymore.

On Linux, rebuilding with hxcpp 4.3.2 didn't work, but I upgraded to latest hxcpp from GitHub and rebuild completed successfully. This is fine. By the time we release Lime 9, hxcpp should be updated on Haxelib anyway.

Anyway, on both Windows and Linux, I could compile and run the Feathers UI components-explorer sample. However, both rendered the window at half of the normal width and height. When I tried to set allow-high-dpi="false", Windows and Linux still had a window at half width/height.