![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
SDL Migration Options
May. 22nd, 2023 04:11 pmI've been using SDL for a long while now. The newest version of SDL 3 will require migrating from SDL 2 versions. Like the switch from 1.2.15 to 2, it will once again break backward compatibility. It will remove support for several older platforms and change the API. The good news is that SDL 3 will have a compatibility layer much sooner than SDL 2 did. I'm still patching some of the SDL 1.2.15 programs I use so that they'll work with either SDL 2 or SDL 1.2.15. In my experiences with it so far, patching seems to work better than using the compatibility layer for SDL 1.2 support. SDL 3 will make more use of the GPU and modern graphics libraries and drivers. From what I've read, it'll introduce a new, portable shader language. So, you may now need more than just a C compiler to write programs. I prefer working with a minimal number of languages and compilers and am not looking forward to some of the new changes SDL 3 may bring. This leaves me wondering if I should seek another graphics/GUI library for more of my development.
I've looked into GUIs, TUIs and graphics libraries in the past and I really wasn't thrilled with most of the options out there. Besides SDL, Raylib seems very promising. It doesn't have the variety of FLOSS applications SDL seems to though. Using OpenGL directly can be just as problematic as SDL because its API keeps changing as well. So, GLFW may not be a great strategy either if the OpenGL compatibility it makes accessible has a changing API. Nano-X seems fairly stable and works on a variety of operating systems. Allegro is often used for applications similar to those created by SDL. However, differences between the versions it supports and what platforms those versions offer is also noticeable. I often use pdcurses with an SDL backend, but pdcursesmod works very well on Windows using Win32 and can also support console mode in Windows and BSD-curses and ncurses offers some benefits over pdcurses on POSIX systems. So, while I've found pdcurses built with SDL highly portable and useful (I even added SDL 2 and SDL2_ttf support), programs that build with pdcurses should port easily to other libraries that don't require SDL.
There are some platforms that only work with SDL 1.2.x and are not supported by later versions of SDL. The same will most likely be true for SDL 2 compared to the latest version of SDL 3. I'm wondering if I should keep using and patching the current SDL 2 and 1.2.15 libraries I've been working with or just make the switch to a new library. I'm also wondering if other developers are in the same situation, trying to determine whether to continue with what they have or port what they can to yet another graphics library or a later version of SDL. If there's interest from other developers in continuing to use older versions of SDL because of platforms they supported or portability issues, it would be nice to collaborate in continuing to maintain these libraries. It's easier to find security issues and bugs when there are a group of users rather than just one programmer using it.
I am currently working on backporting the latest SDL 2 helper libraries so that as many as possible work with SDL 1.2.15. That way SDL 1.2.15 can make use of newer features like loading and rendering SVG images, better utf-8 support, etc. I have a patched version of SDL2_ttf that adds functionality needed for sdl_unifontview to work properly. I've also been adding an alternative build system that doesn't require GNU autotools or cmake. It instead uses CDetect and make.
As one of the earlier contributors to MinGW, I use the original MinGW port to Windows and try to avoid the hostile fork of MinGW whenever possible. Unfortunately, many libraries do not maintain compatibility with the original MinGW compiler. The newer the libraries are, the less compatible they typically are. So, while SDL 1.2.15 is no problem to build with MinGW. SDL 2.26.5 is a nightmare. I'm currently looking into some issues related to building it with the original MinGW now. I maintain my own version of w32api based on the last public domain release and have been trying to add enough functionality to it to compile many of the more modern standard FLOSS libraries. I also built SDL 2 on AIX at one point to experiment with running SDL applications on AIX via X-forwarding. So, I have patches for that as well.
I've started a thread on Mastodon:
https://fosstodon.org/@lmemsm/110413981373101611
Would be very interested to hear how others are dealing with the SDL upgrade path and whether they will be upgrading, staying with what they have or seeking other libraries. If anyone's considering the route of maintaining older libraries, I'd be very interested in sharing resources and patches.
I've looked into GUIs, TUIs and graphics libraries in the past and I really wasn't thrilled with most of the options out there. Besides SDL, Raylib seems very promising. It doesn't have the variety of FLOSS applications SDL seems to though. Using OpenGL directly can be just as problematic as SDL because its API keeps changing as well. So, GLFW may not be a great strategy either if the OpenGL compatibility it makes accessible has a changing API. Nano-X seems fairly stable and works on a variety of operating systems. Allegro is often used for applications similar to those created by SDL. However, differences between the versions it supports and what platforms those versions offer is also noticeable. I often use pdcurses with an SDL backend, but pdcursesmod works very well on Windows using Win32 and can also support console mode in Windows and BSD-curses and ncurses offers some benefits over pdcurses on POSIX systems. So, while I've found pdcurses built with SDL highly portable and useful (I even added SDL 2 and SDL2_ttf support), programs that build with pdcurses should port easily to other libraries that don't require SDL.
There are some platforms that only work with SDL 1.2.x and are not supported by later versions of SDL. The same will most likely be true for SDL 2 compared to the latest version of SDL 3. I'm wondering if I should keep using and patching the current SDL 2 and 1.2.15 libraries I've been working with or just make the switch to a new library. I'm also wondering if other developers are in the same situation, trying to determine whether to continue with what they have or port what they can to yet another graphics library or a later version of SDL. If there's interest from other developers in continuing to use older versions of SDL because of platforms they supported or portability issues, it would be nice to collaborate in continuing to maintain these libraries. It's easier to find security issues and bugs when there are a group of users rather than just one programmer using it.
I am currently working on backporting the latest SDL 2 helper libraries so that as many as possible work with SDL 1.2.15. That way SDL 1.2.15 can make use of newer features like loading and rendering SVG images, better utf-8 support, etc. I have a patched version of SDL2_ttf that adds functionality needed for sdl_unifontview to work properly. I've also been adding an alternative build system that doesn't require GNU autotools or cmake. It instead uses CDetect and make.
As one of the earlier contributors to MinGW, I use the original MinGW port to Windows and try to avoid the hostile fork of MinGW whenever possible. Unfortunately, many libraries do not maintain compatibility with the original MinGW compiler. The newer the libraries are, the less compatible they typically are. So, while SDL 1.2.15 is no problem to build with MinGW. SDL 2.26.5 is a nightmare. I'm currently looking into some issues related to building it with the original MinGW now. I maintain my own version of w32api based on the last public domain release and have been trying to add enough functionality to it to compile many of the more modern standard FLOSS libraries. I also built SDL 2 on AIX at one point to experiment with running SDL applications on AIX via X-forwarding. So, I have patches for that as well.
I've started a thread on Mastodon:
https://fosstodon.org/@lmemsm/110413981373101611
Would be very interested to hear how others are dealing with the SDL upgrade path and whether they will be upgrading, staying with what they have or seeking other libraries. If anyone's considering the route of maintaining older libraries, I'd be very interested in sharing resources and patches.
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}