Upgrade to newer SDL2

[tobybear]

Has anyone tried to update the included SDL2 sources? Zillalib ships with 2.0.3, which is almost 6 years old, and in the meantime there have been big improvements in all areas of SDL, like supporting newer operating systems, input devices, rendering, audio, etc. Unfortunately it is not as simple as just replacing the "sdl" folder with sources from the latest SDL release, so I am curious if someone has already tackled this job, as it does not seem trivial.

[schellingb]

Hello

I think I started an upgrade process twice but I gave up when I realized how much bigger SDL2 has become since.

On Linux an external SDL2 can be used in the build process because our outdated SDL2 straight up crashes on some distributions while on Windows I don't see that many problems. Better input device support would be nice though.

ZillaLib with it's goals to be dependency free and produce small output sizes (often in a single executable) are somewhat at odds with current SDL2. It doesn't want to be statically linked and if forced comes with a ton of overhead.

So instead of fighting with SDL2, I'd love to move the three platforms that use it (Win, Mac, Linux) to glfw and miniaudio or something alike.

You mentioned support for newer operating systems, is there something specific in your mind? I guess Switch is supported by SDL2 (albeit non-publicly) but other than that a move to glfw would not hurt compatibility I think?

Cheers,
Bernhard

[tobybear]

Thanks for your swift response! I would generally love to keep it lightweight as well, and I know SDL has been struggling quite a lot with feature overload and bug fixing.
I am not sure if glfw has the featureset we require, but it might be an option.
SDL introduced support for many different types of input devices in the last years, that was great. Furthermore they now have a cross-platform Vulcan renderer which should make it more future proof. In case you did not know, MacOS 10.14 broke compatibility with all SDL applications and libraries that used it (only black screen visible) which lead to a major outcry and it took until SDL 2.0.9 to finally fix that issue. Now with MacOS 10.15 recently released, a whole lot of other problems occurred.
As for Android, does Zillalib compile with a recent SDK? As running the compiled Android examples no longer work on current Android phones because of security reasons.

[schellingb]

Ouch regarding Android...

GLFW is a popular project with many contributors so I am hopeful that it is at least as compatible and up-to-date as SDL2 (on the three desktop platforms). Adding any rendering support to ZillaLib besides GL (and GLSL/WebGL) would be a giant undertaking which I don't see happening unless I find myself suddenly with a lot of free time or this project somehow becomes much more than it is.

The way Apple is treating OpenGL nowadays is saddening, but the idea of bundling MoltenVK with a ZillaLib game for their platforms is extremely unappealing to me. There was a time where Android and iOS were my top priority in regards to ZillaLib but things have a bit shifted for me, which brings me to this...

It's funny, I wanted to write in my last post that it is essentially just me for now developing ZillaLib so it focuses on what I need/have. My phone still runs Android 6 and macOS 10.14 is all I have access to. My interest has been on WebAssembly recently which is perfect for distributing small games on desktop platforms. I quite dislike how ginormous Android SDK and NDK has become but if the output files straight up refuse to run on newer OS versions I want to look into that. Maybe I can get one of those Android emulators for PC to test.

I know it would be easy to just use SDL2 for all platforms and let them deal with it but that's not fun :-) Also if I can't make 150kb gamejam games what is the point. Now if I could make 64kb games with ZillaLib... mmmh

[tobybear]

I just discovered ZillaLib yesterday but I have been working with a multitude of engines, SDKs and APIs over the last decades (and written a fair share of my own) and I simply love the idea of a lightweight but capable cross-platform C++ engine. Zillalib comes really close to a good featureset for many developing needs in my opinion and I would love to see it used by more people.
I have written a render engine (not for games though) of my own for Windows, Mac and Linux which is based on GLFW, and haven't run into problems with it. So is ZillaLib really only using SDL for window, rendering and system input? Maybe a switch to GLFW would make sense then.
Not sure if it's relevant, but Valve has been a strong force behind SDL in the last years, making it directly integrate with their Steam backend for Windows and Linux and favoring it as the best indie 2D backend for game developers, which is why many people, including me, tend to use it.

[tobybear]

Oh, as a side note, on my Samsung S10 with Android 9 (which will probably get upgraded to Android 10 in the next days), if I disable the app security checks, I can run the Zillalib sample and game apks. There still is a warning message saying this application was not compiled for this Android version which can lead to problems, but it runs fine. At least as far as I could tell, as all of the Android samples seemed to require an attached keyboard and are not working just with touchscreen controls.

[schellingb]

Funnily if I didn't join the games industry professionally, chances of a ZillaLib game coming out on Steam would have been bigger and then maybe my needs would have been different. But as it is I only ever get to use it for small games like last weeks ludum dare game jam.

Yeah SDL is used for Window creation and management, GL context creation, raw audio output, window/input events, fullscreen switching and joystick support. It also does touch screen support on desktop platforms which I have actually used for an interactive toy thing. It uses some multi threading functions offered by SDL but that is a tiny amount of code if we just do Win32 and pthreads.

Maybe we could keep SDL2 support, but remove the included old SDL 2.0.6 and replace it with GLFW for tiny games and offer full support for external SDL2 everywhere (maybe even on non-desktop platforms).

Hopefully building with a newer Android SDK still allows us to be compatible with old Android versions (as many as possible). APKs built by ZillaLib now still run on Android 2.3 because it doesn't use anything fancier than available there. I think it's OK nowadays to increase that OS requirement but shallow security checks alone seem a silly reason to do so.

I tried the BlueStacks Android emulator but it comes only with Android 7 and had no problem running the sample APKs. Touch input worked fine, none of the samples do much with the keyboard but the input one. Maybe old touch APIs got deprecated (again) and an update is needed.

[tobybear]

GLFW also had the problem with black screen in Mojave/10.14, so you would need a rather recent version that has the fix included. Development on MacOS and for iOS is getting increasingly horrible, especially with the deprecation of OpenGL and the new requirements for 10.15 (e.g. requiring Apple to sign your binaries), making me want to step away from this unfriendly infrastructure if only I could.

As for Android topics, I will open up another issue so as not to mix it with the SDL discussion here (I previously assumed you also use SDL on Android in ZillaLib).

[tobybear]

Meh, I just downloaded the latest GLFW for Windows and compiled it as a static lib, and a minimal example already has more than 250kB in file size in release mode.

[tobybear]

Note that GLFW does now always include the SDL game controller database and uses it to handle the multitude of input devices and their button mapping, pretty nice.

[schellingb]

I just played around with it a bit, 2 things are immediately big in GLFW:

• Controller mappings (112kb)
• glad GL function loader (27kb)
  Without these I get the triangle sample to 155 kb (64kb if linking to runtime library as DLL).

The controller mappings we can easily z-compress down to 8kb. GLAD we don't need, it's fine to manually bind only the needed GL functions, ZillaLib already does this.

I also tested with removed EGL and OSMESA support on Windows which removed another 10kb from the exe.

There are 6kb of static data in glfw which is a bit of a bummer because it is just zeroes in the output file it could be replaced by dynamically allocating that memory on load.

Our current slim SDL2.0.6 results in just 44kb binary on Win32 in release (that includes audio), GLFW3 is at 46kb (6kb reduce possible) with audio features not included. Not that exciting but also not devastating.

[tobybear]

Great job! If I find the time, I will check if I can further reduce it (also for my own projects using GLFW).
By the way, the latest ZillaLib seems to use SDL2.0.3 (not 2.0.6), at least according to the headers. Or did I download an older lib version from Github somehow?

[tobybear]

With MacOS 10.15 that was released last week, things got really awful in the software world and most developers are faced with a flood of tickets and complaints.
Any application that has been downloaded from the internet now needs to be signed, hardened and notarized by Apple or Catalina will not allow it to be run. For this you will however need a paid Apple developer account. Sigh...

[schellingb]

Sorry my bad, no idea why I wrote 2.0.6 there, yes 2.0.3 is correct.

Yeah I personally have barely any interest in keeping apple OS support alive and hearing about these changes makes me lose any remaining motivating in regards to them. If they can just go ahead and completely remove OpenGL support there might be a chance I never have to look at Xcode ever again, which would be great (-:

Microsoft kind of started to show some mean messages regarding "unknown" exe files for some users on some Win10 installations which made me worry. That is how Apple started out a few years ago. Personal computing as we know is dissolving in front of our eyes...

[tobybear]

Any plans/chance to replace SDL2 in ZillaLib on desktop targets with pure GLFW? I guess probably not :) ;)

[tobybear]

Almost exactly to the day 4 years later, it's me again. :)
Not sure if this is of interest to anyone out there, but I finally had some free hours today so I experimented a bit with replacing SDL in the desktop versions of ZillaLib. I used tinythreads++ for mutex and threads, sokol_audio for audio interface and GLFW for window and input handling. I had to modify all three new libraries to get them in the shape and size I needed (removed GLAD, Vulkan and the controller database from GLFW for example), but at a first glance, the ZillaLib samples still seem to work.
Filesize is down from 260kb before to 220kb now (and probably quite a bit can still be eliminated), but overall I am not sure if it is worth the effort at all. Particularly the event handling in GLFW is a bit finicky, with extra steps needed to get the correct keys from non-US keyboards.
So I am not sure if I will stick to this or simply let it be as it is with the old SDL implementation.

[tobybear]

An interesting project and maybe a possible alternative to SDL or GLFW is this very lightweight header-only library: https://github.com/ColleagueRiley/RGFW/
If I find the time, I'll try to adapt it to ZillaLib as a new backend and see if I can get it to work.