There are other libraries such as GLFW and SFML that exist and are arguably a lot easier to use. Last time I used SDL2 I was left frustrated over how it needed to hijack main. SDL2 also doesn't have the same portability that SDL1.2 did.
What am I missing? Does it have some feature that none of the other libraries have? I'm assuming there's a reason why it's popular, but what?
SDL is, to my knowledge, older than both of those, so some of the popularity might be a historical artefact from the existence of many tutorials and recommendations from a time before the others existed.
In addition, SDL has been used to port many "serious" games, whereas I see little evidence of that for the others - one might make an argument about production readiness or quality based on that, though again this might be a fluke of history.
Is "hijacking" main a problem for you? I don't know if the same applies to SDL2, but in the original SDL it was possible to use create your own, platform specific "main" if you wanted - SDL providing a default to allow beginners to avoid this detail.
SDL2 is for those that otherwise would write their own window frameworks just to lower the overhead. It does not do much abstraction since many things behave differently on different computers. The only thing I really dislike about SDL2 is the broken Linux installation system that will always crash with dependency problems if you installed any program before SDL and that is something that end users who dont know programming has to live with.
GLFW and SFML that exist and are arguably a lot easier to use
Arguably is a key word in that sentence. Arguably, libSDL2 is easier to use, so you qualify for only a vague response on that.
libSDL2 is still useful, because it's widely used, well known, has plenty of tutorials and example code, and it works well. It's easily available on all popular desktop platforms, mobile devices, and consoles (which is certainly not true of GLFW and SFML) including modern display servers on Linux (also not true of GLFW and SFML, and they have no plans to port to Wayland or Mir), and supports GL and GL|ES contexts and Vulkan is in the pipe. libSDL2 is also actively maintained full time by its original developers and is a commercial product with corporate backing, not a hobby project at the whim of some individuals' spare time.
... it needed to hijack main
libSDL2 does not need to hijack main. On Microsoft Windows a wrapper for main() is provided as a convenience since neither WinMain() nor _tmain() are portable or standard, but there's nothing from stopping you from implementing the necessary stuff in your own Windows-specific main() code if portability is not your concern.
he only thing I really dislike about SDL2 is the broken Linux installation system
Well, that's a property of your Linux distribution. I work with libSDL2 all the time (on Ubuntu), and members of my team are regular upstream contributors so I test their work, and I have never had difficulty installing it or crashes related to dependencies. I would not use a broken Linux package management system as a criticism of an upstream package.
Yeah. Packages are the responsibility of the maintainers, not the code authors. Sometimes it is as easy as right click -> install package, sometimes it is like "download the tarball, make install, and make sure you have GCC 5.4.987 build 3, since previous versions don't implement what I use, and newer versions fix a bunch of implementation details my code depends on"
GLFW and SFML that exist and are arguably a lot easier to use
Arguably is a key word in that sentence. Arguably, libSDL2 is easier to use, so you qualify for only a vague response on that.
libSDL2 is still useful, because it's widely used, well known, has plenty of tutorials and example code, and it works well. It's easily available on all popular desktop platforms, mobile devices, and consoles (which is certainly not true of GLFW and SFML) including modern display servers on Linux (also not true of GLFW and SFML, and they have no plans to port to Wayland or Mir), and supports GL and GL|ES contexts and Vulkan is in the pipe. libSDL2 is also actively maintained full time by its original developers and is a commercial product with corporate backing, not a hobby project at the whim of some individuals' spare time.
... it needed to hijack main
libSDL2 does not need to hijack main. On Microsoft Windows a wrapper for main() is provided as a convenience since neither WinMain() nor _tmain() are portable or standard, but there's nothing from stopping you from implementing the necessary stuff in your own Windows-specific main() code if portability is not your concern.
he only thing I really dislike about SDL2 is the broken Linux installation systemWell, that's a property of your Linux distribution. I work with libSDL2 all the time (on Ubuntu), and members of my team are regular upstream contributors so I test their work, and I have never had difficulty installing it or crashes related to dependencies. I would not use a broken Linux package management system as a criticism of an upstream package.
The player who buys a game for Linux does not care whos fault it is, the game will be blamed if it does not go around the bugs in the system. It either works from the start or leads to a refund.
libSDL2 is still useful, because it's widely used, well known, has plenty of tutorials and example code, and it works well. It's easily available on all popular desktop platforms, mobile devices, and consoles (which is certainly not true of GLFW and SFML) including modern display servers on Linux (also not true of GLFW and SFML, and they have no plans to port to Wayland or Mir), and supports GL and GL|ES contexts and Vulkan is in the pipe. libSDL2 is also actively maintained full time by its original developers and is a commercial product with corporate backing, not a hobby project at the whim of some individuals' spare time.
It seems you are only using SDL, because GLFW does have support for Wayland/Mir, its only still called experimental.
Afaik SFML has support for mobile.
It seems you are only using SDL, because GLFW does have support for Wayland/Mir, its only still called experimental.libSDL2 is still useful, because it's widely used, well known, has plenty of tutorials and example code, and it works well. It's easily available on all popular desktop platforms, mobile devices, and consoles (which is certainly not true of GLFW and SFML) including modern display servers on Linux (also not true of GLFW and SFML, and they have no plans to port to Wayland or Mir), and supports GL and GL|ES contexts and Vulkan is in the pipe. libSDL2 is also actively maintained full time by its original developers and is a commercial product with corporate backing, not a hobby project at the whim of some individuals' spare time.
Afaik SFML has support for mobile.
Well, no I work on Mir, and I'm intimately familiar with the state of support for modern display servers in GLFW. It's a compile-time-only switch. That's the equivalent of no support for Mir or Wayland, unless you're going to be building a dedicated embedded device or something.
Also, SFML has support for mobile "coming soon." Phones have been around for decades, if support for them isn't there by now you've missed the boat.
The player who buys a game for Linux does not care whos fault it is, the game will be blamed if it does not go around the bugs in the system. It either works from the start or leads to a refund.
Sure. That's certainly a traditional problem on Microsoft Windows (the classic DLL hell), and has been a problem on other operating systems too. It's certainly irrelevant to a comparison of portable frameworks like libSDL2 vs. SFML vs. GLFW. Fortunately there are obvious and widely-adopted solutions, such as packaging for a distro (on Linux) or bundling your dependencies (on Mac OS X, Microsoft Windows, through Steam, or using modern Linux packaging such as flatpack or snaps).
Notice that all three libraries use the zlib/libpng license, so you're free to statically link or redistribute the libraries with your game. You have no excuse if you distribute your game in such a way that it breaks due to ABI mismatches with other software installed on a user's computer. This is especially true for GLFW and libSDL2 which are C libraries (SFML is a C++ library and engenders all the ABI headaches related to that).
I like SDL 2.x a lot. The current iteration of the library is well laid out and works without fuss or hassle. I wasn't as fond of the 1.2 system, and elected to write my own per-platform code from scratch when our current engine iteration was started. Later on when a Linux port became necessary and SDL2 had been released, I just forwarded my platform code to SDL and it worked beautifully. The main hijack is helpful on a number of platforms (most obviously Windows but on iOS as well) and makes things easier in the end.
This topic has been locked by a moderator. New replies are not allowed.
GameDev.net uses cookies to ensure you have the best experience on our platform. Learn more
