(off topic) I always think it's a bit funny how different developers version number things. SDL is nearly thirty years old and just hit version 3. Google Chrome is just over 16 years old and it's...
(off topic)
I always think it's a bit funny how different developers version number things. SDL is nearly thirty years old and just hit version 3. Google Chrome is just over 16 years old and it's at version 132. GIMP hit version 2.0 in 2004 but 3.0 just recently hit release candidate status. Meanwhile Windows through 10 and 11 have had like 6 feature releases that could have been major versions. It's just all over the map and the numbers mean nothing anymore.
Anyway, does anyone still develop with SDL these days?
The numbers do mean something, but not when comparing different software. The versioning schemes are just used to communicate different information at a glance. Some software uses semantic...
It's just all over the map and the numbers mean nothing anymore.
The numbers do mean something, but not when comparing different software. The versioning schemes are just used to communicate different information at a glance.
Some software uses semantic versioning, where major versions are used to denote breaking changes. Others use a date-based scheme, like Ubuntu. Others are completely arbitrary, like the Linux kernel.
Chrome's is based on iterating the major number after their 4 week release cadence. This makes sense for rapidly developed software that needs frequent short-term feature freezes with high stability goals. Browsers rarely break backwards compatibility, so denoting breaking changes doesn't make much sense for them.
Choosing the versioning scheme that makes the most sense just depends on the type of software and environment it's being developed in, and sometimes comes down to preference. Comparing the absolute numbers between different versioning schemes won't really mean anything, though.
In my experience, a lot of stuff runs SDL under the hood, especially game engines such as Valve's Source Engine. It's a very easy way to bootstrap an app or program in a cross-platform way.
In my experience, a lot of stuff runs SDL under the hood, especially game engines such as Valve's Source Engine. It's a very easy way to bootstrap an app or program in a cross-platform way.
Huh, after a little digging it seems like this is one of the prevailing underlying stacks that are still used. My experience with SDL was having to delve into dependency hell on slackware to get a...
Huh, after a little digging it seems like this is one of the prevailing underlying stacks that are still used. My experience with SDL was having to delve into dependency hell on slackware to get a game to run under SVGA on a textmode linux install 20+ years ago. Impressive that it's lasted this long, and this is truly an historic release. Sorry if I seemed flippant about it; I respect the open source developers who've progressed it this far for this long.
It's the simplest way to get some pixels on the screen and start making a game (from first principles). And it does input handling pretty well, too. And they've just made audio part of the package...
It's the simplest way to get some pixels on the screen and start making a game (from first principles).
And it does input handling pretty well, too.
And they've just made audio part of the package as well.
SDL3 has been usable for a while, so my personal project's already ported to it. It's not a complete paradigm shift or anything, but the API is quite a bit nicer now, and there are some very...
SDL3 has been usable for a while, so my personal project's already ported to it. It's not a complete paradigm shift or anything, but the API is quite a bit nicer now, and there are some very welcome improvements. SDL is and always has been fantastic; it's my recommendation for anyone looking to write a cross-platform game.
Oh this is exciting. I've used SDL2 quite a bit and generally liked it. Experimenting with this may be the motivation I need to start some new project. Particularly I want to try out their new...
Oh this is exciting. I've used SDL2 quite a bit and generally liked it. Experimenting with this may be the motivation I need to start some new project. Particularly I want to try out their new graphics API. I'm curious how far one could go without using any direct lower-level API calls (ex. no explicit DX or VK calls).
(off topic)
I always think it's a bit funny how different developers version number things. SDL is nearly thirty years old and just hit version 3. Google Chrome is just over 16 years old and it's at version 132. GIMP hit version 2.0 in 2004 but 3.0 just recently hit release candidate status. Meanwhile Windows through 10 and 11 have had like 6 feature releases that could have been major versions. It's just all over the map and the numbers mean nothing anymore.
Anyway, does anyone still develop with SDL these days?
The numbers do mean something, but not when comparing different software. The versioning schemes are just used to communicate different information at a glance.
Some software uses semantic versioning, where major versions are used to denote breaking changes. Others use a date-based scheme, like Ubuntu. Others are completely arbitrary, like the Linux kernel.
Chrome's is based on iterating the major number after their 4 week release cadence. This makes sense for rapidly developed software that needs frequent short-term feature freezes with high stability goals. Browsers rarely break backwards compatibility, so denoting breaking changes doesn't make much sense for them.
Choosing the versioning scheme that makes the most sense just depends on the type of software and environment it's being developed in, and sometimes comes down to preference. Comparing the absolute numbers between different versioning schemes won't really mean anything, though.
In my experience, a lot of stuff runs SDL under the hood, especially game engines such as Valve's Source Engine. It's a very easy way to bootstrap an app or program in a cross-platform way.
Huh, after a little digging it seems like this is one of the prevailing underlying stacks that are still used. My experience with SDL was having to delve into dependency hell on slackware to get a game to run under SVGA on a textmode linux install 20+ years ago. Impressive that it's lasted this long, and this is truly an historic release. Sorry if I seemed flippant about it; I respect the open source developers who've progressed it this far for this long.
It's the simplest way to get some pixels on the screen and start making a game (from first principles).
And it does input handling pretty well, too.
And they've just made audio part of the package as well.
This is great!
SDL is usually an underlying technology for a number of game engines. LÖVE - something I am working with right now - uses it.
Windows on its own is a circus... Numbers to years to names, back to numbers, skipping a number.
SDL3 has been usable for a while, so my personal project's already ported to it. It's not a complete paradigm shift or anything, but the API is quite a bit nicer now, and there are some very welcome improvements. SDL is and always has been fantastic; it's my recommendation for anyone looking to write a cross-platform game.
Oh this is exciting. I've used SDL2 quite a bit and generally liked it. Experimenting with this may be the motivation I need to start some new project. Particularly I want to try out their new graphics API. I'm curious how far one could go without using any direct lower-level API calls (ex. no explicit DX or VK calls).