search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
10k stars 1.85k forks source link

Platform review #6570

Closed slouken closed 1 year ago

slouken commented 1 year ago

Review the set of supported platforms. Are there any that we should remove due to lack of active maintainer?

Platforms:

Audio subsystems:

Video subsystems:

Misc:

@libsdl-org/a-team

sezero commented 1 year ago

Reverted opengles removal now.

slouken commented 1 year ago

Reverted opengles removal now.

Thanks!

slouken commented 1 year ago

We need to do a little more research before we pull the trigger on WinRT removal, so I added it back temporarily in https://github.com/libsdl-org/SDL/commit/a635a485bcd926a128ffc4b78cb82105bc351360.

sezero commented 1 year ago

We need to do a little more research before we pull the trigger on WinRT removal, so I added it back temporarily in a635a48.

https://github.com/libsdl-org/SDL/issues/5842 stayed open for about 4 months and no one was even polite enough to say 'f... off'. Doesn't that give an implication as to how much use our WinRT code has?

flibitijibibo commented 1 year ago

Yeah, as far as I could tell FNA was the last user of UWP, and we've made it pretty clear that it's unsupported:

https://github.com/FNA-XNA/FNA/wiki/Appendix-F:-Upcoming-Support-Changes#uwp-support

slouken commented 1 year ago

It's being used for Hololens development, apparently. I'm not permanently bringing it back, I just wanted to make sure that nobody needs it before it gets nuked, while it was still easy to revert.

past-due commented 1 year ago

We need to do a little more research before we pull the trigger on WinRT removal, so I added it back temporarily in a635a48.

To follow-up on this (and something that was said earlier):

While it's true that the "Windows Store no longer requires UWP", it does not mean that "you can use GDK on PC" in all of the same circumstances. The base license terms for the GDK may be incompatible with certain situations (or other licenses) that are used with apps using UWP today.

Additionally:

Additional licensing is required to obtain the Xbox Extensions to build games optimized for Xbox consoles or publish games to the Microsoft catalog for any platform.

(Source: https://github.com/microsoft/GDK/blob/Main/README.MD)

So from that standpoint, there can exist applications that may currently be able to use UWP, but that may not be able to use the GDK (due to licensing constraints / conflicts).

sezero commented 1 year ago

So from that standpoint, there can exist applications that may currently be able to use UWP, but that may not be able to use the GDK (due to licensing constraints / conflicts).

And they can always use SDL2, can they not?

past-due commented 1 year ago

And they can always use SDL2, can they not?

Certainly - I just bring it up as a data-point. (Given past headaches due to projects stuck on SDL1, not able to benefit from the numerous improvements and fixes in SDL2.)

To clarify: I'm not commenting on whether it's worth keeping the UWP platform support, given the (apparent) deprecation status and likely lack of maintainers on this end.

Just that it's not always a drop-in UWP -> GDK replacement. (At least, currently. GDK licensing could theoretically change again in the future.)

sezero commented 1 year ago

Just that it's not always a drop-in UWP -> GDK replacement. (At least, currently. GDK licensing could theoretically change again in the future.)

In any case, a platform support should have at least one active maintainer, where, with the WinRT case, no one seems to have volunteered. (see e.g. #5842.)

Cacodemon345 commented 1 year ago

To clarify: I'm not commenting on whether it's worth keeping the UWP platform support, given the (apparent) deprecation status and likely lack of maintainers on this end.They haven't really clarified the policies regarding UWP games that much to my understanding. And they still mention Xbox Live Creators Program in their System Requirements page as well as their own official site. They mentioned UWP as one of the ways to create Windows apps this year.

RetroArch is still riding the UWP horse, and so is the few UWP emulators that still exist. It's pretty clear that we will be dealing with UWP as long as it still exists as a game and emulator development platform and as long as they don't officially shut down the program or actually give us another viable method to develop games for Xbox without the chance of running into troubles with NDAs and license conflicts.

slouken commented 1 year ago

I am able to build and test UWP code here, so in a pinch I can look at UWP issues on Windows. Given that people are actively developing and publishing with it, let's leave it as a viable SDL3 platform.

slouken commented 1 year ago

The OpenGL ES 1.0 2D renderer has been removed.

isage commented 1 year ago

Also, this might be too aggressive, but I'd consider deleting PSP, Vita, PS2, and Nintendo 3DS support up front, and let them live in SDL2, and add them back to SDL3 if they want to maintain them once we've ripped everything up. Obviously the Stadia fork is not migrating to SDL3. The other private forks will, I assume. Do we need "android", "aaudio" and "opensles" audio targets? What is Android using at this point? Can "jack" audio go away now that pipewire is the new hotness? Did NetBSD ever pick up ALSA or PulseAudio, or do they really still need a bespoke /dev interface?

Agreed, about time to focus mainly on shader capable renderers. PSP, Vita, PS2 and Nintendo 3DS can live inside SDL2 branch.

Vita renderer is shader-capable (you actually can't render anything at all without shaders)

Wohlstand commented 1 year ago

About WinMM: there is a case at my buddies where they had ASUS Xonar sound cards and running Windows 10, the WASAPI just sucks (inconsistent volume levels, etc. That happens at their machine only, doesn't happen at others), and using DirectSound while works, it has another bug: when ANY DirectSound application client gets crashed or killed, last played audio buffer chunk will remain sound permanently and no way to get it rid without the whole reboot of the computer. So, WinMM is a saviour from that freaking bug. Also, certain users reported to me that DirectSound doesn't work at all on their machines (I don't remind which OS, possibly Windows 8 or 8.1), but WinMM worked just fine. So, I vote we should keep WinMM too as a fallback, even for modern Windows.

elahav commented 1 year ago

I was about to submit a small fix for the QNX audio plugin when I noticed that support was removed. Can it be brought back? Last time I made a fix QNX contributed a licence to the SDL project so it can at least be built. If the licence expired I'm sure we can get a new one.

JohnnyonFlame commented 1 year ago

kmsdrm without EGL/GBM (using dumb buffers)

Doable. I have began experimenting with this as a peer requested such functionality, but went with a different route afterwards. You can find said proof of concept here. I also developed a drm+dumbbuffer backend for SDL1.2 with the folks at the OpenDingux distro which is a whole lot more mature and feature complete.

Don't treat this as a PR proposal, only posting it for reference. The code is known to have problems such as:

If this is interesting to anyone, it should be fairly straightforward to pick it up from here. In such case, feel free to ping me at the SDL discord if necessary.

EDIT:: Interesting to note here too is that it's not an incredibly useful way to handle things on embedded since you have no way to point the renderer directly to the dumb buffers, having to instead rely on a shadow buffer (created by CreateWindowFramebuffer), in contrast with SDL1.2 which gave you a direct pointer to these buffers.

Maybe this is something a future version of SDL could provide?

icculus commented 1 year ago

I was about to submit a small fix for the QNX audio plugin when I noticed that support was removed. Can it be brought back? Last time I made a fix QNX contributed a licence to the SDL project so it can at least be built. If the licence expired I'm sure we can get a new one.

We removed it because no one was available to maintain it (and we likely can't add it to GitHub Actions without publishing a private license key, even if we still had one that worked).

That being said, I'm 100% okay with putting QNX back in if someone checks in on the code from time to time.

icculus commented 1 year ago

So there's still some desire for the GLES1 renderer...the concern isn't so much older hardware, but that it happens to work across a lot of platforms (and, in rtrussell's case, he wants to call GLES1's glLogicOp() directly, which was dropped in GLES2).

This is in regards to this thread:

https://discourse.libsdl.org/t/with-the-new-sdl3-will-be-sdl2-abandoned/41322

I'm not against finding some way to supply this that doesn't include having it in SDL3, like we did with the gesture stuff...in this specific case, they're using the SDL2 renderer API but require it to use GLES1 under the hood, so it's not a question of API compatibility, which is to say if there's a reasonable way to split it out, it doesn't really matter that they would lose access to Direct3D, Metal, GLES2, etc, because they wanted to avoid those anyhow. At least, that's my understanding.

I don't have a plan at the moment, and the easiest thing to do is just re-add the GLES1 renderer and be done with it, but I'd like to solve this for rtrussell in some form or another.

elahav commented 1 year ago

I can certainly volunteer to maintain the QNX port, as I use SDL extensively to test the sanity of kernel changes. I was about to post a pull request to bring back the QNX code, but then noticed the change from autotools to cmake, which is going to require some work. I can't promise when I'll have something ready, but it's good to know the project is open to accepting the code.

slouken commented 1 year ago

I'll go ahead and close this. It seems like, except for QNX support which may come back, this is a good list of platforms to clean up for SDL3.