amiberry
amiberry copied to clipboard
BlitterStudio
Upgrade to SDL3
Now that SDL3 is released, it should be tested to see how well things work with it. The migration guide is here: https://github.com/libsdl-org/SDL/blob/main/docs/README-migration.md
SDL3 releases: https://github.com/libsdl-org/SDL/releases
This should be done in a separate, test branch. I suspect it will take quite a while before everything is migrated properly and we will need time for testing things.
Check if all supported platforms have SDL3 available.
Man, that's quite the API change ~ having moved this box to debian testing (trixie), I see libsdl3-0 (-dev) are available targets, so that probably infers adoption in debian next at a guess...
...just ftr, there's enough different between bookworm and trixie, that I use a different box for testing amiberry against debian bookworm, so once you spin-up a separate branch, it's easy enough for me to test things ;)
Current state of play ... https://packages.debian.org/search?searchon=sourcenames&keywords=libsdl3
HTH
I tested a build with sdl2-compat and got an assert in a mutex. Seems a work in progress worth to be checked again later.
Well, this issue is about moving the code to use SDL3 directly, not through a compatibility layer. It's a long-term project, since it will take a while to do so, and we'll probably have to keep SDL2 around for a while longer as well (at least until SDL3 is available everywhere, not sure if it's in the older distros).
I tested a build with sdl2-compat and got an assert in a mutex. Seems a work in progress worth to be checked again later.
What version of sdl2-compat? If it's the same issue I ran into it was fixed in the newest versions of sdl2-compat and SDL3 see https://github.com/libsdl-org/sdl2-compat/issues/264
However, this does go to show, that taking some time before adopting SDL3 might be beneficial.
Please don't do that. Stay on SDL2. We don't need SDL3 on Raspberry Pi. This will break all compatibly with old system...
Just tapping out time ~ SDL3_image (-dev) has made it's way into debian trixie repo now, so wrt debian, we're just waiting for SDL3_ttf to roll down from sid ... I'll likely chirp again when that is so ;)
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/179
For general awareness, I'm linking this issue from the Wayland protocols repository. IIUC the short version of it is that Wayland does not expose a concept of "primary display", so compositors implement this independently (Mutter for Gnome, Kwin for KDE, cosmic-comp for CosmicOS, etc.).
This means that for users with more than one display, it's undefined where the SDL window will open. This issue seems to be especially noticeable where a non-native Wayland application is involved (e.g. when running it through Xwayland).
Good to see SDL3 is on a ToDo. Just letting you know that we can test it quickly on all platforms/architectures and Debian (library) versions, since we compile SDL ourselves. Though with KMS/DRM + GL/GLES/potentially Vulkan backends only, no plans for X11 or Wayland support so far.
If/as sdl2-compat works, does anyone know whether there are potential issues/downsides in combination with Amiberry? I mean aside of potential bugs in that layer, more like whether it provides the complete SDL2 API and on the SDL3 side the complete set of features and behavior expected by Amiberry? We could swap our bundled SDL2 to SDL3 + SDL2 compat quickly, I guess, but I hesitate in case there are known limitations. Otherwise we could provide dedicated packages for testing exactly that.
in the early days of SDL3 sdl2-compat had a lot of problems (no audio or audio stuttering, slowness etc) but that has been ironed out by now.
