Hi Folks,
Looking at the page: SDL2/Libraries - SDL Wiki, some of these extensions look like they would make sense to be included in the “core” SDL capabilities that come when you pass the “-lSDL2” linker flag to the linker for C++. Specifically SDL_image, SDL_mixer, and SDL_net all seem like they would be very useful (and likely necessary) when constructing a game. How come they aren’t included in the core SDL2 functionality and have to be added as additional linker libraries?
Thanks,
Dave
Not everyone needs them. Even when you do, they bring in lots of external dependencies, which not everyone wants to deal with.
For loading images, stb_image is a lot easier to include in your project and get building on multiple platforms than SDL_image since it’s just a single header file library. In fact, SDL_image uses stb_image internally for loading PNGs now (and possibly other image formats).
For audio, it just depends on what you need. A lot of developers are going to want something more like FMod or Wwise. And, again, SDL_mixer has a lot of external dependencies.
I don’t think SDL_net ever saw any major use.
Thanks, sjr. Yeah, that does make sense about dependencies. I saw your post on the other question about stb_image being the key ingredient to SDL_image. I ended up not using SDL_image and instead using one of the header only alternatives that uses stb_image (so I suppose I didn’t use stb_image directly). Though, I was having other issues with not being able to invoke the SDL extended libraries in my project and needed an some alternative. That had kind of got me thinking, “Why aren’t these part of core anyway?”. Good point.
Cheers
Also note that SDL_image is only useful when using SDLs 2D rendering (either the SDL_Surface software rendering stuff or SDL_Renderer) - lots of games use OpenGL or Vulkan or whatever directly, because they’re 3D or they want to use shaders in 2D, and for them getting textures as SDL_Surface doesn’t help much (and SDL_Texture even less).
Though OTOH, having an stb_image based subset of SDL_Image (basically SDL_stbimage.h) in core SDL might be nice, because out of the box SDL only supports BMP which isn’t that great (esp. when using alpha) - and it wouldn’t add external dependencies, and not that much code bloat either.
As sjr said, instead of SDL_Mixer, many games use FMod or OpenAL or even some custom thing, so it’s not generally useful either.
And yes, SDL_net doesn’t seem to be used much, probably often makes more sense to use a higher level networking lib like enet or yojimbo or something - and if you want to roll your own, the Socket APIs on different operating systems aren’t that different (I think basically it’s either WinSock or proper BSD/Unix Sockets) so it’s feasible to do the OS abstraction yourself
This is great info on the alternatives to sound and network support. I’m not aware of them yet and will look them up. Also, thanks to your header only implementation of stb_image.h I was able to work in the loading of PNG textures into an object in my project with no issues! the instructions are very clear.
Sadly, I’m not one of the cool kids yet…
Thanks,
Dave
Sadly, I’m not one of the cool kids yet…
Yeah, that comment kinda aged badly because in SDL3, SDL3/SDL.h will be the standard (I think at least partly because Apple enforces that kind of include for frameworks?) - but in SDL2 #include <SDL.h> was/is the recommended way, for example sdl2-config --cflags returns -I/usr/include/SDL2 (at least on my system).
(I’m not suggesting you should change it now, it doesn’t really matter as long as it works and it’s closer to SDL3)
I use it! I don’t take advantage of its more ‘unusual’ features, and I’d be just as happy with an interface more similar to native sockets, but I appreciate the cross-platform incompatibilities being taken care of without me needing to worry about them.
SDL_net is sort of the black sheep of the satellite libraries, as it was an answer to a problem that existed before platforms consolidated around BSD Sockets. MacOS Classic had “Network Sprockets” or something totally alien to our current system APIs.
Thankfully SDL_net doesn’t need much upkeep in its current form, but in many cases it risks limiting apps (for example, its current API is hardcoded for IPv4), and it has some other goofy design decisions.
Generally I tell people to use something else, like enet or libcurl or whatnot, and if they need TCP streams or UDP packets specifically, just use BSD Sockets directly, and paper over the minor differences with WinSock with a handful of #defines.
That being said, we do still accept patches to SDL_net, and there was at least the start of a discussion here somewhere about what a reasonable API might offer if we ever decided to start from scratch on it (but no one is seriously talking about doing that at this moment in time).
I use SDL_net in all my network games! I’ve only ever used TCP but for my real-time WW2 game Firefight I think I’m gonna need UDP so hope that’s easily do-able…
Are these arcade games?
I use UDP with SDL_net, seems to work.
Two are card games (Niggle and Wizard), one is a strategy game (Slay) and one is a clone of the board game Risk (Conquest). They’re all turn based, so TCP was OK, but my real-time WW2 game (Firefight) is gonna send a lot of data.
I wonder how it’ll turn out. I can’t imagine playing a fast arcade game over the internet.
