Suggestion to consider modularity of SDL and separate libraries
ell1e opened this issue · comments
My apologies if this has come up before, and I mentioned it in some comments but never as a dedicated issue: there seems to be a growing array of increasingly non-trivial amounts of growing code parts and larger modules that isn't that interesting to a larger subset of SDL apps. I'm not sure if this is useful at all, but I wanted to throw the suggestion into the room to make them separate to bring down build time and complexity for core lib users.
What seems like candidates to a naive user from the outside like me:
-
Audio: With the audio subsystem now including more indirection and an entire audio mixer etc., some engines may want to use their own audio subsystem instead. Since I assume the core event loop and handling doesn't really depend on it much, maybe it would be worth making some sort of
SDL_Audiolib. -
2D Render API: With many apps just using OpenGL or vulkan themselves, this seems like component that will often go untouched while I assume at this point with the whole draw ordering etc. being big enough to possibly consider being separate as
SDL_SimpleRenderlib or such. -
Cloud and filesystem API: There seems to be a growing interest in handling cloud saves, generally handling save games, and more advanced filesystem handling. Especially non-games will probably use their own libraries for that, so maybe moving these out into some sort of
SDL_Resources, as in external resources handling helpers, might be worthwhile.
Sorry if all of these are a bad idea, and it's instead best kept in one thing. I have to admit I've used projects with far worse build times, it's just something that occasionally makes me wonder given where SDL seems to be moving.
I mean, the thing is, the audio subsystem could offer less and be a bad fit for a specific engine/game, too. We can't build something that's perfect for everyone.
We've always made it so you can use what we offer but aren't forced into it and won't interfere if something else is used (like, audio won't even look at the system APIs and hardware until initialized, so slotting in fmod or wwise or OpenAL doesn't have a conflict).
I don't think we should split up the library into component parts...it would add confusion to save a few hundred kilobytes of disk space.
I do think it would be interesting to see if static linking plus dead code elimination could mitigate this, but I also haven't tried.
We don't recommend static linking, but you can always build SDL with major subsystems disabled for your use case.