With the new SDL3, will be SDL2 abandoned?

Or, does SDL2 will be updated in parallel with the 3?

1 Like

not abandoned in the sense that there will be a compatibility package to ensure that all SDL2 apps will still run under SDL3

All SDL2 apps? Mine uses (and requires) the OpenGLES (1.2) backend, which I understand will no longer be supported in SDL3, so I don’t think it will run. I would expect, and am relying on, SDL2 being supported for the foreseeable future.

I think the idea is that code written for SDL2 which doesn’t rely on specifics of SDL’s backend internals should continue to work when using sdl2-compat.

Public APIs to create OpenGL ES 1 contexts still exist in SDL3 (and should work as long as the operating system and graphics driver supports that - which might not be forever), but an OpenGL ES 1 SDL_Render backend doesn’t exist anymore. So if your code uses those public APIs then it will still work, whereas if your code relies on a SDL_Render backend implicitly providing something despite SDL_Render already not guaranteeing anything about its backends, then your code might not work.

To future-proof your code, you could avoid relying on SDL_Render backend details.

No, I could not. My code - and my users’ code, since my app is a programming language - makes (very) extensive use of the SDL2 rendering API, particularly for outputting graphics. It would be completely impractical to avoid that, indeed impossible whilst maintaining compatibility with existing programs.

The only occasion when I bypass the SDL2 API and call an OpenGL function directly is in order to support plotting graphics in an OR, AND or Exclusive-OR plotting mode (which the particular programming language I am implementing requires). I do that by calling the glLogicOp() function.

Mixing calls to the SDL2 rendering API with calls to the OpenGL API is supported, indeed it’s the very reason for the existence of the SDL_RenderFlush() function: “call this function [if] you are planning to call into OpenGL/Direct3D/Metal/whatever directly in addition to using an SDL_Renderer”.

I cannot ‘upgrade’ to SDL3, so I am relying on continuing support for SDL2 (at least to the extent of fixing issues arising from updates to the underlying OS, e.g. Android or iOS).

The entire GLES1 renderer backend in SDL2 is about 1k lines. Replicating just what you need in your own code with your own abstractions might be somewhere around 1k-2k lines (accounting for what you’d have to replicate from the higher level SDL_Render code.) It wouldn’t be a no-effort change to do that, but neither is it impractical or impossible unless your users are calling SDL_Render and OpenGL APIs together directly with no way for your programming language to redirect any of that (which seems unlikely to me because that’s certainly possible in things I’ve made, and if you’ve tied your users to SDL2’s APIs so thoroughly, well… I’d definitely suggest taking steps to untie that for the future.)

Whether the added control is worth it for you is up to you of course.

There are functions which let SDL users interact with platform- and backend- and implementation-specific details of SDL_Render, but that doesn’t mean the specifics of each individual interaction are guaranteed to be supported forever (for example the available backends can change, and the implementation of a given backend can change), and it does mean here be dragons.

This isn’t the only time your project has had friction with relying on implementation specifics of SDL_Render, I suspect it won’t be the last time either which is why I keep trying to suggest solutions that will end up with less friction in the long run. :slight_smile:

My users (and language libraries) are calling SDL_Rander and OpenGL APIs, but you also need to remember that desktop OpenGL continues to support glLogicOp() (it’s only OpenGLES 2 which doesn’t) so your proposal would mean the regular SDL_Render API being used on desktop platforms but the ‘replacement’ code on mobile.

There’s not the slightest possibility I would attempt that when I can simply continue to use SDL2, with which I can use identical code on all platforms (which is sort of the point of an abstraction layer like SDL). There are people using SDL1 in new designs now, so I am just going to have to assume that SDL2 will keep working just as long.

I don’t really understand the rationale for removing OpenGLES 1 from SDL 3 anyway. It remains supported in Android and iOS and I’m not aware of any intention to remove it, I would guess that maintaining support for it would have been very little effort, so I can’t help thinking it was an arbitrary decision, taken with no consultation (that I’m aware of).

Specifically? I do push SDL2 to its limits, but I’m not aware that I rely on anything undocumented. Anyway, my app is finished, I do not intend to do any further work on it (I have been diagnosed with Alzheimer’s Disease so I am not going to be able to anyway).

I stopped at SDL 2.10, and if I cared about what I was diagnosed with, I wouldn’t be able to do anything. :slight_smile: No point in going to doctors these days…

1 Like

Specifically? I do push SDL2 to its limits, but I’m not aware that I rely on anything undocumented.

No, SDL2 does allow mixing SDL_Render and OpenGL, see SDL_GL_BindTexture().
That was probably the biggest mistake in SDL2 (this already became apparent when SDL_Render got non-GL-backends).

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

I’m sorry to hear that :frowning:
I hope a cure is found in time (sometimes miracles medical breakthroughs happen, right?), and otherwise that it progresses as slowly as possible :heart:

1 Like

I understand why you say that, but (if it helps) I am extremely grateful for the “mistake” because it has allowed me to do so much more than would otherwise have been possible. Of course it would be great if SDL could ‘natively’ do all those things - and it is getting closer with functions like SDL_RenderGeometry() - but that is a lot to ask.

Yes, mercifully so far deterioration has been slow, and even the diagnosis is tentative (based mostly on short-term memory tests and an MRI brain scan; a PET scan didn’t show the characteristic beta-amyloid plaques). The only reliable way to diagnose it is post-mortem, and I hope that won’t be for a long time!

Metal doesn’t support those fixed-function pixel logic operations at all. Only about half of Vulkan drivers support them. So, of the actively developed public graphics APIs only Direct3D 12 unconditionally supports fixed-function pixel logic ops. OpenGL may disappear on Apple platforms in the future (since it has been formally deprecated there for years) - and the trajectory for it on many platforms in the past few years has been pointing to having implementations that call into more modern APIs instead of each driver maintaining their own code.

There was the whole line drawing thing a year ago. Differences in rendering across platforms got solved (which is great) but you also pushed for a specific line drawing implementation to be done inside SDL’s code because your app relied on undocumented specifics of how SDL line drawing worked in the past. At the time Ryan also suggested you take whatever implementation works best for you and have its code in your own app so you aren’t relying on SDL internals like that.

The one that worked for your project ended up being implemented via hints in SDL, but it’s probably not healthy for SDL if it happens a lot.

I’m sorry to hear that.

It’s not like per-pixel fixed-function operations are particularly difficult to perform in modern APIs anyway. Most of them can be replaced with a trivial pixel/fragment shader. (Now we just need SDL custom shaders, and we’re good!)

FWIW, with the SDL3 GPU feature, mixing the “simple” SDL_Renderer 2D API with a more powerful 3D API will be possible, without exposing platform-specific implementation-details.
I fear that won’t help your specific usecase much though, because SDL GPU won’t expose that kind of fixed function features (because most of the underlying APIs don’t support them).

OTOH, the functionality can probably be reimplemented with rendering to a framebuffer object (or texture) and then using that as a source for a pixelshader that implements the logic operations (by applying them to the old pixel from the framebuffer object and the new pixel from the current draw command)?
Won’t be as easy as before I guess, but probably feasible?

Yes, mercifully so far deterioration has been slow, and even the diagnosis is tentative

I’ll keep my fingers crossed!

Now that I’ve thought about this a bit more I’m not so sure anymore.
I hope I’m not talking too much nonsense here, I only know a little OpenGL (3+) and hope to have a vague idea of how “modern” GPUs (read: ones not older than 15 years or so :-p) work. Could be that this was true when OpenGL 3/4 was current but is not anymore on newer hardware.

I don’t know if @rtrussell requires that kind of functionality, but if I understand glLogicOp() correctly, you can set it and then you can (if you want) in each following draw call draw over the same pixels over and over again, and each time that operation gets applied based on what you wrote to the pixel last time.
This is pretty different to “I draw some kind of background in one rendering phase, and in the next phase draw stuff on top, using the ‘background’ as one input in the pixel shader and apply logical ops between background and new pixel”.

Because this means that the GPU can’t parallelize draw calls very much - one must have finished, so its output can be used as input for the next one. I think that modern GPUs don’t support this very well, which is why pixelshaders usually don’t support reading the existing color value of the pixel they’ll write to (so even in “modern” OpenGL, blending still is fixed function and not done in shaders).
See also A trip through the Graphics Pipeline 2011, part 9 | The ryg blog (“Aside: Why no fully programmable blend?”).

(There’s an OpenGL (ES) extension to support this: https://registry.khronos.org/OpenGL/extensions/EXT/EXT_shader_framebuffer_fetch.txt but that extension isn’t widely supported as far as I know - at least my nvidia desktop driver doesn’t support it)

Sure. You can’t do it the same way, but you can still trivially accomplish the same thing by not doing it in multiple steps. Just set all of your “draw stage” values as inputs to a single shader, which samples and blends them sequentially.

If this won’t work because you need distinct blend steps because they aren’t all working on the same regions of screen space, you can use a render target as an intermediate sampleable framebuffer. But consolidating it down into as few steps as possible by using multi-input shaders is still a very good idea.

Of course it may disappear, but if I adopted that negative attitude I would never have developed my application in the first place! Anyway I don’t think it’s likely that iOS is gong to drop support for OpenGLES any time soon.

It’s noteworthy, I think, that although I get warnings from Xcode that my use of launch images is deprecated, I get no warnings at all about my use of OpenGLES! Nor do I get any warnings about it when I submit my application to the iOS App Store.

Because OpenGL (or OpenGLES) is currently available on every platform I support (Windows, MacOS, Linux, Android, iOS and in-browser) I have been able to implement 3D graphics and shader programming in a fully-compatible way across all those platforms.

That is simply not true. I have only ever relied on the documented behavior that “SDL_RenderDrawLine() draws the line to include both end points”. The claim that I pushed for a “specific line drawing algortihm” is also untrue; I may have suggested an algorithm as one way of ensuring that the documented behavior can actually be relied upon, but that’s all.

That’s correct, but conceptually it’s no different from any other non-trivial blend function, such as you can already achieve using SDL_ComposeCustomBlendMode(). In fact, the most common of the glLogicOp() modes that I use - invert - is perfectly achievable using a custom blend mode!

SDL2 is about 10 years old now, so I think it makes sense to assume for SDL3 that OpenGL (even more so ES 1.x) might not be supported on Apple OSs anymore in 5-10 years (TBH I wouldn’t even be surprised if they discontinued it next year), and that even Android might drop at least GLES1 in the foreseeable future.
And on the other hand, all relevant hardware and operating systems (that support OpenGL at all) support at least GLES2 (or Desktop GL3), so it makes sense to discontinue GL(ES)1 support in SDL_Renderer from a maintenance point of view - even though it clearly sucks for the one user who needs it because GLES2/3 don’t support glLogicOp() :-/

Fair enough, but in that timescale I would expect SDL3 (or SDL4!) to provide cross-platform native support for 3D graphics and shader programming that could replace the OpenGL calls I currently use - not necessarily including glLogicOp() but who knows. :wink:

I don’t hugely care whether I use OpenGL, Metal, Vulkan or some native SDL equivalent so long as it does what I need and is available in a fully-compatible way on every platform I want to support. Currently, as in the last ten years or so, only OpenGL(ES) can meet that requirement.

If I am unlucky, and Apple discontinue support for OpenGL before a cross-platform replacement is available, then I - or whoever is maintaining my app then - will have a problem. But that bridge can be crossed if and when it happens.

What I can’t accept is the counsel of despair which suggests that because that’s a possibility I should abandon my app now, or indeed shouldn’t have ever written it in the first place.

My understanding is that SDL GPU (for cross-platform native 3D) will be part of the first SDL3 release, so if BBCSDL can be ported to use shaders instead of relying on fixed-function features, there shouldn’t be a problem (apart from having to implement it), and the result should be fairly future-proof.

No idea when SDL3 with SDL GPU will be done, though - if an estimation (more specific than “when it’s done”) exists I haven’t seen it yet. But it’s very actively being worked on.

No one says you should abandon your app, we’re only saying that relying on having GLES1 or desktop GL available on all relevant platforms is not future-proof, even medium-term :slight_smile:
I’m sure that viable solutions exist, even if I’m personally not sure how easy they are to implement if you require glLogicOp() in all its flexibility (but I only have limited experience with modern 3D APIs, so take this with a grain of salt)