SDL Abandoned, and What I Did Instead

Sunday, 28th January 2024

Last month I posted an article "A Future Development for CGALIB" about how I was planning to add SDL2 support to the CGALIB Graphics Library. A month later, and that hasn't happened. In this article, I'll tell you why, and what I ended up doing instead.

For those who don't want to read the previous article (and I don't blame you), the idea was that SDL2 support in CGALIB would allow me to develop my CGA game projects under a modern operating system, with the advanced debugging tools available. A useful side effect would be that I would be able to port those projects to modern operating systems easily.

One thing got in the way, though: SDL2. Specifically, its performance and reliability on the two Linux systems I regularly use for development. I would implement something that worked on one system, but it wouldn't work on the other. I'd get it working on both systems, only for the unchanged code to fail to work days later.

After a few weeks of getting nowhere, with help from some kind respondents on Stack Overflow and on Mastodon, I decided to put SDL2 aside and try my luck with libX11 instead. The libX11 side quest went almost without a hitch. Before long I had the CGA Robots game working perfectly under Linux. And my primary goal, of being able to develop and debug in Linux, was satisfied.

As part of this exercise, I've integrated keyboard control into the development version of CGALIB, and plan to also do the same with PC speaker audio. This allows me to abstract the keyboard/audio code in the same way as I've abstracted the graphics, so that the project will still compile and work under both Linux and DOS.

Sadly I've given up on my secondary goal. In theory, I could use the libX11 version of CGALIB to release Linux version of my CGALIB games. But in practice, I'm very far from doing that. The reasons are multiple:

1. The interface is far from satisfactory for a release quality game. There's no fullscreen option. Operating System events aren't recognised, so if you switch to another virtual desktop and back again, the graphics are gone. Addressing these shortcomings now would take a lot of time away from the primary target platform, DOS.

2. While I've integrated keyboard control into CGALIB, audio will not be as easy. I can see no easy way to get Linux to emulate the DOS sound() and nosound() functions, which are used for music and sound in the PC Speaker library. Linux audio libraries are all about loading and playing audio files; nobody wants to beep nowadays. The best I'll be able to do for development purposes is to allow the Linux program to call my speaker library's music and sound effect functions; I won't be able to make the resultant sounds and music. This would also have been true had I pursued SDL2 integration.

3. Even if I find solutions to both the above problems, it would be far easier to take advantage of the DOSBox licence, and release Linux, Windows (and Mac) versions of my games by bundling DOSBox with them. This I could also do for games that use existing versions of CGALIB that don't support a modern OS directly.

So, now that I've got development moving on Linux, and I have an alternative way to release Linux/Windows/Mac versions of my games, I don't see the point in continuing the fight with SDL2 for the time being.