One of my favorite new C tricks is linking arbitrary files to a binary using the gcc flags -Wl,–format=binary -Wl,–foo.ext -Wl,–format=default and then accessing the contents with asm(_binary_foo_ext_start).
Since SDL can load most (all?) of its supported graphical and audio structures from memory with the magic of RWops, why not package things together (for example, all the sprites and audio for a level) into a library (eg .dll) and load/free it dynamically just like from file? Of course you’d also have a library for stuff like the player avatar’s assets and such so that you can reduce redundancy and manage the life of those separately.
Advantages I can think of are:
Enforces organization of assets so that you can’t load something when you don’t need it and won’t forget to free something you no longer need.
Turns runtime and logical errors into compile time errors. If you don’t have the file for a spritesheet present, the build of the library will fail at the linker stage rather than letting it succeed only to later fail when it tries to load at runtime. Of course, with dynamically loaded code, you can still forget the whole library, but this should be way easier to catch.
Assets are more tamper-resistent and better hidden. They look like any old dll that most players won’t want to mess with, and there’s no need for encryption! Might still be a good idea though…
Cleaner deliverable. Hundreds of spritesheets? Not anymore! Just a handful of libraries that can fit neatly into a folder in a subdirectory.
But what are some disadvantages to something like this? Would it take more memory or be slower? More prone to break? Let me know what you think!