追溯到几年前,但记录在2022年, 的愿望 为跨平台游戏流行的SDL硬件/软件抽象层提供抽象文件系统API。随着SDL 3.0添加的新SDL_Storage接口,这终于成为现实。
简单DirectMedia层(SDL)多年来一直非常成功地将各种子系统抽象为从视频到输入、音频、线程等,以便跨平台工作。最新的工作是SDL_Storage,以便更好地抽象文件系统交互。除了前面链接的问题跟踪器, 这张票 去年总结了对SDL文件系统API的需求:
Windows. Windows是问题所在。
- Windows希望你在Unicode文件路径中使用UTF—16字符串,其他所有东西都需要UTF—8。
- Windows希望你使用Win32 API,其他所有都使用POSIX。
-Windows希望您使用FILETIME(从1601年开始以100纳秒为增量),其他一切都使用POSIX(time_t,unix纪元)。
-Windows希望您使用‘\’,其他所有内容都使用‘/’
- Windows有驱动器号,其他都有装载点。
- 在现代,Windows有符号链接,许多其他东西总是这样。但有些事情根本就不是!
SDL_Storage最终致力于解决这个问题,并提供了从Windows到Linux、macOS和各种控制台平台的更通用的文件系统API。著名的游戏搬运工和FNA—XNA开发者Ethan Lee接受了开发SDL_Storage的挑战。他在现在合并的SDL_Storage代码中解释道:
这就是我对存储API的想法;title和用户存储之间有明显的区别,这假设应用程序根本没有对任何磁盘的自由访问权。当使用这个API时,你可以假设你的文件系统代码应该在合理的情况下工作(即我们现在没有在有效/无效的路径规则上乱折腾)。
这意味着在低级别使用原始SDL_filesystem API和使用更高级别的文件系统库(如PhysicsFS)之间存在,后者允许虚拟文件系统格式和mod支持等更好的特性。对于那些只需要读取标题数据、读取/写入保存数据、完全不需要其他操作的应用程序来说,这应该是理想的API。
...
包括一个通用的实现以及Steamworks实现的存根,SDL和SteamRemote Storage API非常接近,所以这是绝对可能的,它只需要输入。然而,这对于那些需要显式安装文件系统来完成这项工作的控制台来说更有用,但是由于它们是NDA,所以很难将其包含在这篇文章中:(
此合并请求 今天登陆SDL Git,以获得最初的SDL_Storage支持,现在将进一步建立在此基础上, SDL 3.0.