The wiki page for SDL_Init doesn’t seem to indicate a reason why you wouldn’t just init everything all the time.
Can folks give some example of when you’d not want to just call SDL_Init(SDL_INIT_EVERYTHING)?
For games, you’ll probably be initializing everything, but I really like SDL outside of the context of games too… for example, using SDL and SDL_net to make a simple HTTP server, and here is how I initialize SDL: SDL_Init(0) - no audio, no video, no timers, not even events… because an HTTP server doesn’t need to take joystick input, rather all I need are pretty much just threading and synchronization primitives (which are available even with SDL_Init flags of 0).
If you are curious, look at line 876 [at time of writing] in this file in the repository for the server code: http://gitlab.glassbladegames.com/rsethc/smh/blob/master/smh/smh.c
Some might find it strange that I would choose SDL for a project like this since usually SDL is associated with games, but I am familiar with it, like the API a lot for its simplicity, and thanks to the flexibility of SDL_Init’s behavior controlled by those flags, I can get all of the threading stuff that I need while also telling SDL not to bother with loading the video and audio systems that I don’t need, saving a bit of startup time and memory. I haven’t tested this, but it also may allow my server application to successfully start up in some environments where SDL_Init would indicate failure due to inability to initialize the video subsystem in the absence of a window manager, for example.
3 Likes
Ah, hmm. That makes sense. In the language I’m using they’ve got Networking and Threading in the standard library, but not Audio, Video, or Gamepad, so those are the ones I had focused my attention on. I slightly forgot about the other sub-systems.
I am pretty sure it is because loading more things mean taking more RAM.
You usually don’t want to saturate your RAM with unused SDL modules.