SFML 3.1 Is Released(github.com)
github.com
SFML 3.1 Is Released
https://github.com/SFML/SFML/releases/tag/3.1.0
5 comments
Genuine question; why would I want to use this over SDL?
SFML historically was a little more accessible if you were an OOP programmer but a total beginner to working with audio/graphics/networking programming from a game perspective. You had to be OK with or devoted to OOP/classes, want a higher-level library with a few more batteries included (especially cross-platform input and networking) but less flexibility, don't need to target game consoles, don't want or need to work in C, and are primarily or only working in 2D.
That said, even for those uses SDL2 (much less SDL3) caught up to SFML about 6-7 years ago in usability issues for people without experience coding at that level. Circa 2015, SFML was the easier route to both performance and a working cross-platform binary. That hasn't been true for a long time now, even when SFML started to get refurbished around 2021/2022. The only times I've come across SFML since 2017/2018 have been projects migrating off of it and onto SDL 2 or 3.
It's good to have both SFML and SDL, among other C++ options and other-language frameworks. Even looking at 3.1, I don't think I'd recommend SFML now, especially not for the same reasons I might've done it 10 years ago. But it's good to see them modernizing anyway, and changes like this might make it easier to update and maintain old or abandoned projects that still use SFML.
That said, even for those uses SDL2 (much less SDL3) caught up to SFML about 6-7 years ago in usability issues for people without experience coding at that level. Circa 2015, SFML was the easier route to both performance and a working cross-platform binary. That hasn't been true for a long time now, even when SFML started to get refurbished around 2021/2022. The only times I've come across SFML since 2017/2018 have been projects migrating off of it and onto SDL 2 or 3.
It's good to have both SFML and SDL, among other C++ options and other-language frameworks. Even looking at 3.1, I don't think I'd recommend SFML now, especially not for the same reasons I might've done it 10 years ago. But it's good to see them modernizing anyway, and changes like this might make it easier to update and maintain old or abandoned projects that still use SFML.
As maintainer I won't be able to give you an unbiased response. The biggest difference is, that SFML is a C++ library.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
I appreciate the response. I've actually got my own platform-layer which can be a bit like SDL/SFML in shape at times, so I totally understand the desire to work on that kind of problem. I'm good with different competing solutions in similar spaces, as well. I don't think one library to rule them all is necessarily a good idea.
Lately I've been doing the experiment of just forgoing the library entirely for this kind of code. It's a bit like gradually building up my own SDL/SFML directly in-place. I'm sure people would find that wasteful or odd, but I enjoy learning the differences in the platforms, and being better positioned to integrate with a particular platform. I'm also shipping way less code. Although admittedly I'm not sure if I'd do this if I were a C++ dev, I write Odin and part of the experiment is putting Odin through its paces and seeing how well it fits in this part of the stack (very happy so far.)
Lately I've been doing the experiment of just forgoing the library entirely for this kind of code. It's a bit like gradually building up my own SDL/SFML directly in-place. I'm sure people would find that wasteful or odd, but I enjoy learning the differences in the platforms, and being better positioned to integrate with a particular platform. I'm also shipping way less code. Although admittedly I'm not sure if I'd do this if I were a C++ dev, I write Odin and part of the experiment is putting Odin through its paces and seeing how well it fits in this part of the stack (very happy so far.)
If you are interested in a hybrid solution, I've been working on a fork of SFML which uses SDL as the backend, among many other improvements:
https://vittorioromeo.com/index/blog/vrsfml.html
https://vittorioromeo.com/index/blog/vrsfml.html