isledecomp
feat: SDL2 shim for ports without SDL3 support
Everything works as far as I can tell.
I would appreciate some help with the build script refactoring.
Uses system SDL2.
~~Does anyone know why SDL_MAJOR_VERSION doesn't seem to be defined in the runner? It works locally.~~
Could I get some help with this? The game starts and loads the intro animation then freezes and gets stuck in a loop at https://github.com/isledecomp/isle-portable/blob/57e918904cd30e112829a0b366606ac2ecb94bd0/LEGO1/lego/legoomni/src/video/legovideomanager.cpp#L304-L307
I assume theres some subtle SDL2 difference that i missed which is causing this..
Changing UseSurface() it always return true "fixes" the issue. Maybe SDL2 and SDL3 aren't firing the same events leading to the state not being the same for loading and rendering.
Works if you comment out https://github.com/isledecomp/isle-portable/blob/6ea82ae144b91874bd41fe32e9ffb82507a87ef0/LEGO1/omni/src/video/mxstillpresenter.cpp#L96-L97
We should have at least one CI build that tests this.
Are there any ports lined up that will make use of this? I wouldn't want to add this complexity if it won't actually be used.
Are there any ports lined up that will make use of this?
I've made this with the intention of using devkitpro's ogc-sdl-2 branch for a wii port.
This patch is slightly smaller then the wii patch for SDL2. I think it would be better use of your and our time to add proper wii support to SDL3.
Since wii is not supported anymore by Nintendo, the SDL project should be welcoming to maintain it as part of SDL3 (unless the port is doing unholy illegal things).
This patch is slightly smaller then the wii patch for SDL2. I think it would be better use of your and our time to add proper wii support to SDL3.
Most of the lines in this are simple #defines (or commented copy pastes from the migration wiki) I really doubt migrating devkitpro's SDL2 patches to SDL3 will be less work.
You already did a big job by making it SDL2 compatible, so moving SDL completely out, should be a refactoring job. (Don't worry about supporting multiple SDL versions by one binary)
I give this approach a NAK. This gives us a big technical debt. Platforms should either all get sdl3 support, or isle-portable should get an intermediate layer.
I helped adding such a layer in dethrace: it supports SDL 1, 2 and 3. (All in a single binary)
I agree with this take.
I would suggest using C++ objects rather then C structs and pointers like dethrace, but other then that I agree and abstraction with multiple implementations would be more maintainable then making SDL2 look like SDL3
How would you want such an intermediate layer to be laid out? Prefixing everything in INTERMEDIATE_ over SDL_ and ifdefing its definition? I feel like that's way way more work than whats currently happening.
How would you want such an intermediate layer to be laid out? Prefixing everything in INTERMEDIATE_ over SDL_ and ifdefing its definition? I feel like that's way way more work than whats currently happening.
Let's call this new layer mortar (as it connects blocks/bricks), so prefix with MORTAR_? (we can always change it)
There should be no ifdefs in isle and lego1: everything is a proper MORTAR_ definition/function where SDL is an implementation detail.
This probably also means the new layer will have to translate the various SDL events to something generic.
It should be possible to add an extra mortar backend for a completely different backend (e.g. glfw3, raylib, sokol, win32, ...) without changing anything in isle and lego1.
A first step would be to move all SDL3 things from isle and lego1 to a mortar library. (the SDL3 headers should only be included by its private cpp/h files, and must not be present in its public h headers.)
Here's an extra motivation for adding SDL3 support for the Wii (and attempting to upstream it):
The main reason upstream SDL does not have a Nintendo Switch support is because Icculus (one of the SDL main devs) signed a Nintendo NDA and does not want to get in trouble.
Nintendo Wii is a legacy platform, so this limitation does not longer apply there.
I'm not active in the Wii homebrew scene, so perhaps you can motivate people in doing this (and also sticking around to fix and advise on various Wii issues).
I disagree. I don't know how would that be any different than an making an SDL2 shim. After all, many platforms still only have SDL2 (or even SDL1), not just GameCube and Wii. Even if the PR author intended the shim to be used for a Wii port, it doesn't mean it couldn't be used for future ports. You don't need to port SDL3 first, just use the SDL2 shim, make some tweaks for the platform, and et voila.
IMO, isle-portable shouldn't use SDL3 in the first place. I think it would do just fine with SDL2, even if isle-portable targeted modern computers first and legacy platforms second. You know what, I actually agree with the intermediate layer thing. ClassicCube and Scratch Everywhere already does it (even though the 99% of the ports on latter are literally just SDL2). It would take a very long time to decouple isle-portable from the SDL3isms though since it's extremely dependent on SDL3.
Sdl3 made both 3d rendering and web port easier, it was the right choice in many ways
me personally don't know if it should've written in sdl2 from the beginning, but i do agree that for future ports having sdl2 layer is good
it's good if you port sdl3 to your desire console but that's too much work than just using existing sdl2 lib and since (afaik) we're aiming for easy portability i think it's a 'why not' question to have a sdl2 layer
me personally don't know if it should've written in sdl2 from the beginning, but i do agree that for future ports having sdl2 layer is good
it's good if you port sdl3 to your desire console but that's too much work than just using existing sdl2 lib and since (afaik) we're aiming for easy portability i think it's a 'why not' question to have a sdl2 layer
yeah that's what i'm saying
me personally don't know if it should've written in sdl2 from the beginning, but i do agree that for future ports having sdl2 layer is good
it's good if you port sdl3 to your desire console but that's too much work than just using existing sdl2 lib and since (afaik) we're aiming for easy portability i think it's a 'why not' question to have a sdl2 layer
Honestly my exact thought process and why I chose this path. Both porting the SDL2 wii patches to SDL3 and replacing SDL3 with another layer of abstraction seems like wayy more work than what this shim is.
(I already have a working wii port with this shim.)