SDL Storage API Merged For SDL 3.0
The Simple DirectMedia Layer (SDL) has been very successful over the years for abstracting various subsystems from video to input, audio, threads, and more for working across platforms. The latest effort is on the SDL_Storage for better abstracting file-system interactions. Besides the aforelinked issue tracker, this ticket last year summed up the desires for an SDL file-system API:
Windows. Windows is the problem.
- Windows wants you to mess with UTF-16 strings for Unicode filepaths, everything else wants UTF-8.
- Windows wants you to use Win32 APIs, everything else uses POSIX.
- Windows wants you to use FILETIME (100-nanosecond increments since 1601), everything else uses POSIX (time_t, Unix epoch).
- Windows wants you to use '\\', everything else uses '/'
- Windows has drive letters, everything else has mount points.
- Windows sorta has symlinks in modern times, many other things always do. But some things don't at all!
SDL_Storage ultimately works to address this and provide more common file-system APIs that work from Windows to Linux, macOS, and various console platforms. Well known game porter and FNA-XNA developer Ethan Lee took on the challenge of working out SDL_Storage. He explained in the now-merged SDL_Storage code:
This is what I had in mind for storage APIs; there is a distinct difference between title and user storage, and this assumes that the application does not have free access to any disks at all. When using this API, you can assume that your filesystem code should work in sandboxed environments, within reason (i.e. we're not messing around with valid/invalid path rules right now).
This intends to exist between using raw SDL_filesystem APIs at the low level and using higher-level filesystem libraries like PhysicsFS which allow for fancier features like virtual filesystem formats and mod support. For apps that just need to read title data, read/write save data, and absolutely nothing else, this should be the ideal API.
...
Included is a generic implementation as well as a stub for a Steamworks implementation, the SDL and SteamRemoteStorage APIs are super close so it's definitely possible, it just has to be typed out. However, this is much more useful for consoles which require explicitly mounting filesystems to do this work, but since they're NDA it's hard to include as part of this pitch :(
This merge request landed today in SDL Git for having the initial SDL_Storage support that will now be further built upon for SDL 3.0.
18 Comments
