With the new SDL3, will be SDL2 abandoned?

If you build the SDL2 Xcode project for iOS while using the iOS 12.0 SDK or later (Apple currently requires using the iOS 15 or 16 SDK when submitting to the App Store) you will get dozens or hundreds of warnings about OpenGL ES functions being formally deprecated. I haven’t tested with the CMake build setup but I’d be surprised if it does anything special to suppress those warnings.

On macOS it normally would be similar when you build SDL, but SDL has some #pragma preprocessor statements sprinkled in its macOS backend to suppress those warnings. That doesn’t mean Apple isn’t giving those warnings though, just that they’re being ignored.

In your own app, if you get those OpenGL / OpenGL ES functions from Apple’s headers they will have the same deprecation warnings. If you get the function pointers manually via SDL_GL_GetProcAddress or similar APIs, that information isn’t part of the pointer so the warnings will be lost.

I didn’t think web supported fixed-function logic ops (WebGL 1 is based on OpenGL ES 2, WebGL 2 is based on OpenGL ES 3, and WebGPU is based on the minimum of what D3D12/Vulkan/Metal support so doesn’t have them either.) What do you do on that platform?

I’m not sure this falls under documented behaviour or that it has no reliance on what’s going on under the hood, but I suppose you can draw your own conclusions from that whole thread. I’m not really interested in arguing, I’ve just been trying to suggest writing code to reduce that sort of reliance and improve long term viability (maybe the opposite of abandoning things.)

This is great news for reducing your reliance on glLogicOp. :smile:


As mentioned, there are plans for a platform-agnostic GPU API in SDL3… but actually there are non-SDL alternatives already which can be used together with SDL. So you don’t need to wait for SDL’s version of that if you don’t want to. I can’t speak to their quality though :slight_smile:


To go back to the original thread post, as far as I can tell SDL2 will continue to be patched for bug fixes for a while yet, it’s just not getting new feature or major change development - for example a fully supported Wayland backend which is used by default instead of the X11 backend where possible is a SDL3 feature and I don’t think there are plans to make it the default in SDL2.

To answer the original question: I don’t know how this will shake out specifically yet, but we have a lot of commercial games on Steam, and elsewhere, that depend on SDL2 and are likely not going to migrate to SDL3 because they aren’t getting updates anymore and we will not abandon them outright.

My assumption is that we will be doing more SDL2 releases to make bugfixes. It’s not impossible that small API additions could happen for an SDL2 release if an urgent need arises, but ideally all of that goes into SDL3 now if we can tolerate it. I assume we’re probably not going to be doing quarterly releases of SDL2 going forward, because that takes an enormous amount of effort. It’s possible it’ll be back to a “this is enough fixes for a bigger release, let’s do it,” or it’s possible we’ll just keep doing monthly point releases with some good stability improvements each time. But at least for the foreseeable future, the real SDL2 is still going to be maintained.

Someday in the (distant?) future, the real SDL2 will be like the real SDL 1.2: we accept patches in revision control, we don’t work on it ourselves, and we won’t do further official releases, but that’s a long long time from now.

Right now we’re still taking a chainsaw to SDL3–and then later a scalpel, I hope–so it’ll be awhile before we can ship a serious release of it, which means no matter what SDL2 needs to remain viable and maintained in the meantime.

Unlike sdl12-compat, we have not waited a decade before starting sdl2-compat. As changes are made to SDL3, we fill in the compatibility layer. Eventually I envision this being the way we use SDL2, and certainly the way you use SDL2 if you want access to modern platform features (for example, sdl12-compat allows Linux apps to use Wayland, or Windows apps to use WASAPI, even though the real SDL 1.2 doesn’t support those things). Eventually I assume that Linux distros and the Steam Runtime will ship sdl2-compat as if it were the real SDL2, and will personally advocate for that.

Right now sdl2-compat is broken every other day as we change big things in SDL3, but that will calm down over time…it’s possible it stops needing any serious attention once SDL3 stops changing APIs. sdl12-compat takes heroic efforts to make ancient programs not just work, but work better (you can play virtual audio CDs from a directory full of MP3s, software rendering gets pushed off to the GPU, it’ll try to scale tiny game windows for 4K monitors, etc). My hope is that we are doing less of that in sdl2-compat and more just acting as a bridge between APIs. Time will tell.

tl;dr: SDL2 will not be abandoned, and we are focused on making sure it continues to work even once SDL3 is mainstream.

4 Likes

As for GLES1: we’ll figure something out, but I haven’t decided what yet (maybe it goes back into SDL3, maybe we find a way that doesn’t suck to get the heavy lifting moved into the app, maybe we make sdl2-compat offer it so you can get on the latest SDL without losing access to this).

I have been diagnosed with Alzheimer’s Disease so I am not going to be able to anyway

As for this: you have always pushed me to build better things, and I will not abandon you, either.

3 Likes

I am building with the latest version of Xcode (no CMake or anything like that) and, as I said, I get no warnings at all about OpenGLES from either the build or the App Store submission process. Here is the App Store entry for my app.

I think you do get warnings when building with OpenGL for MacOS but I am definitely getting none when building for iOS.

My application is only partially functional when running in a browser. That’s not just down to the absence of glLogicOp() but, even more fundamentally, to the absence of network connectivity (I do specify the -s USE_SDL_NET=2 switch but that provides an interface to WebSockets only).

It’s a shame, but it’s better than having no support for running in a browser at all.

In any blend mode other than the trivial SDL_BLENDMODE_NONE drawing the same pixel more than once has an effect different from what that blend mode specifies. So you couldn’t argue, for example, that drawing the entire line twice is compliant with the docs.

So yes I do think the ‘drawing each pixel only once’ behavior is implied by the docs, but since it is not stated explicitly there is more room for interpretation and argument, if you are so inclined.

Curcumin is almost proved be efficient in slowly Alzheimer, and beetroot too (90% slowly that disease) Vegetable compound could have a key role in ‘beeting’ Alzheimer’s disease | USF News Maybe you must change eat habits to some more “natural” like.

In the current subject. I don’t wanna relearn to use SDL, but I know that we must evolve and is natrual with the project SDL. So, someone can show me how it will be a simple “hello window” in SDL3? Or some link to it?

Just a little aside here: this is only a thing with desktop GPUs. Most, if not all, mobile GPUs are tile-based, and can read from the tile buffer from within the fragment shader. In fact, Apple’s GPUs (including the M-series ones used in new Macs) don’t have blending hardware; the driver appends some code to the end of the fragment shader that reads a pixel from the tile buffer and blends it with the shader output. That’s why frequently changing the blend state in OpenGL ES can be expensive (the driver has to change the shader code), and why the blend state is baked into the pipeline state along with the shader in Metal.

Both OpenGL ES and Metal provide facilities to do your own reading from the tile buffer in a fragment shader; in OpenGL ES it’s an extension, and in Metal it’s part of the regular API.

I imagine the situation is similar in Android-land

3 Likes

SDL/README-migration.md at main · libsdl-org/SDL · GitHub has an overview of changes - but note that SDL3 isn’t done yet, so more changes will (most probably) come.

SDL/test at main · libsdl-org/SDL · GitHub contains SDL3’s tests, SDL/testdrawchessboard.c at main · libsdl-org/SDL · GitHub is a simple one that (at least currently) uses plain SDL code (instead of additionally using the SDL_Test framework, like most other tests do)

1 Like

@sjr: Interesting, thanks for the clarification! :slight_smile: