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. 
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. 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 
I hope a cure is found in time (sometimes miracles medical breakthroughs happen, right?), and otherwise that it progresses as slowly as possible 
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. 
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
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)