Migrate Lime on native platforms to use SDL3

[EliteMasterEric]

SDL just released version 3.1.3 stable API preview, which means that (while the library still has bugs and issues to resolve before the 3.2 stable release), no existing functions will be removed, making it stable enough for migration.

There is a very long list of useful features that migrating would enable (see the list at the link), and also a long list of issues that are resolved by updating (such as #1569), but this first requires migrating the existing places that SDL2 are used.

I originally attempted this myself by just editing the existing implementation last year, but this resulted in a bunch of graphical glitches, so updating would probably require someone more experienced with C++ and graphics APIs.

[EliteMasterEric]

Some features we may find relevant (now or in the future) include:

• Using nanoseconds for timestamps in various places
• Using OS timestamps for input events (rather than the SDL timestamp, making it way more accurate)
• Replacing TinyFileDialog with a more flexible and well-maintained implementation
• Support for clipboard data of any mime type
• Improved audio stream handling
• New storage and file-system APIs that work across platforms
• The new SDL Graphics API, providing access to cross-platform graphics and compute.

Plus any fixes from newer versions of SDL 2.x.

[Fancy2209]

I am willing to give a jab at this since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get things to work.

[EliteMasterEric]

I am willing to give a jab at this since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get things to work.

Great to hear! I'm interested to know whether you think there will be major benefits to using SDL GPU over OpenGL

EDIT: @Fancy2209 Please check this out if you haven't: https://github.com/libsdl-org/SDL/blob/main/docs/README-migration.md

[Fancy2209]

I am willing to give a jab at this since I'm interested in eventually allowing Stage3D from OpenFL to use SDL GPU and as far as I know 3.1.6 is already pretty usable. Will post updates as I get things to work.

Great to hear! I'm interested to know whether you think there will be major benefits to using SDL GPU over OpenGL

EDIT: @Fancy2209 Please check this out if you haven't: https://github.com/libsdl-org/SDL/blob/main/docs/README-migration.md

The major benefit I see in SDL3 is portability

Instead of needing to maintain specific backends for platforms (like having a D3D12 backend for Xbox, GNM on PS4/5, Vulkan on Switch, GLES on Android, whatever whatever) lime could just keep the OpenGL/WebGL and the SDL GPU backend. SDL GPU could even allow WebGPU on Web as I believe that's a wip. Keep in mind I'm not a licensed console developer but I know maintaining the console versions has been an issue for lime before.

The other point is many people have been asking for OpenFL and Lime to support more"modern" graphics APIs instead of OpenGL and I believe SDL GPU is the easiest way to do this, as it'll allow support GNM, D3D12, Vulkan and WebGPU with one API.
TODO is to see how hard this'll be, it seems mostly doable but shaders might be a pain, hopefully there's a way to translate GLSL with SDL ShaderCross (or maybe I'll need to translate GLSL to Spir V and then use ShaderCross for platforms without it? Eh problem for later)

Performance improvements I'm not sure but it's probable, we'll know when it's done.

I'll first just port lime to SDL3 though, then look into GPU, as I believe the first thing will already be quite a big thing and I don't want to do an unreviewable PR.

Also I've seen the migration guide before, but I do appreciate pointing to it.

[Fancy2209]

I have gotten OpenFL to boot with SDL3, for some reason the asset system is failing to parse the manifests so I had to replace the bunnies with a black bitmapdata, but it works!

[pozirk]

SDL really needs to be updated. :)

With Android API 35+, Google introduced edge-to-edge and turned it on by default: https://developer.android.com/develop/ui/views/layout/edge-to-edge
Now If app is not in fullscreen mode, system and navigation bars overlap the app.
New SDL hopefully has a fix.

Any news on migration?

[dimensionscape]

I want to clarify some things, because there is a little bit of an unnecessary urgency to migrate to SDL3. First, lets note that SDL2 is still actively maintained with up to date QoL updates and will be for the time being. (see https://github.com/libsdl-org/SDL/commits/release-2.32.x/)

Now If app is not in fullscreen mode, system and navigation bars overlap the app.

I dont know if SDL provides adaptation for this yet (maybe it does?) but there's no need to push the panic button yet. It's possible there is already a patch or perhaps we just have to handle insets ourselves in lime. Either way, we're not going to let issues like this go unresolved.

Migration to SDL3 is going to happen, hopefully sooner than later, but there's no inherent urgency yet.

[joshtynjala]

In 8.3.0-dev, I added an option to control Android’s behavior. For now, anyway. I read that they’ll eventually ignore this option completely, so everyone will be forced to support edge to edge rendering in all apps, no opt-out.

41ac2fc

In the same branch, I also added a safeArea property to allow apps to move items so they won’t be covered by cutouts.

af22996

I think I exposed it in OpenFL 9.5.0-dev too.

So we shouldn’t strictly require any SDL updates in Lime.

[pozirk]

Ok, that's great, I'm looking forward to the new release.