虚拟文件系统
大多数游戏的资源（模型、纹理等）都打包到特殊文件中（例如 Quake 3 中的 .pk3 文件）。显然，这些文件以某种方式被“安装”并像单独的文件系统一样使用。
我想知道这是如何实现的。到目前为止，我想到的唯一策略是将偏移大小信息放置在文件头中，然后对文件进行内存映射并访问资源，就好像它们是独立的写保护内存块一样。
我想知道我的策略是否可行以及是否有更好的替代方案。
谢谢！
Most games come with their resources (models, textures, etc.) packed into special files (like .pk3 files in Quake 3 for example). Apparently, those files somehow get "mounted" and are used as if they were separate file systems.
I'd like to know how this is achieved. The only strategy I came up with so far is placing offset-size information in the file's header, then memory-mapping the file and accessing the resources as if they were independent write-protected chunks of memory.
I'd like to know if my strategy is viable and if there are better alternatives.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你的策略很合理；事实上，它与文件系统驱动程序对原始块设备的作用完全相同。您在实施过程中遇到什么问题？
Your strategy is quite reasonable; in fact, it's an exact analogue of what a filesystem driver does with a raw block device. What problems are you having with that implementation?
你的做法听起来很合理。基本上您将拥有一个包含（可选）元数据的 ISAM 文件。您可以根据条件（内容类型、使用频率、使用位置等）将文件拆分为多个部分（“目录”），并为每个部分提供单独的索引/目录。如果您允许节作为内容类型，那么您可以嵌套它们并以一致的方式处理它们。
如果您的要求相当基本，您可以考虑简单地使用 zip/tar 文件作为容器。无论如何，查看这些代码可能是一个很好的起点。
Your approach sounds reasonable. Basically you'll have an ISAM file with (optional) metadata. You can split the file into sections ("directories") based on criteria (content type, frequency of use, locality of use, etc) and have a separate index/table of contents for each section. If you allow a section as a content type, then you can nest them and handle them in a consistent fashion.
If your requirements are fairly basic, you could consider simply using a zip/tar file as a container. Looking at the code for these would probably be a good place to start, regardless.
我不能透露 Quake3 的确切格式，但有几种方法可以满足您的需要：
这些方法中的每一种都有其自己的优点和缺点。
我们的SolFS产品就是上面提到的虚拟文件系统的一个例子。它是为与您类似的任务而设计的。
档案和一些复合文件实现通常具有线性顺序结构 - 文件被一个接一个地写入，某些目录位于文件的开头或结尾。
一些复合文件实现、数据库和虚拟文件系统具有基于页的结构（“页”类似于 FAT 或 NTFS 中的扇区或簇），其中文件可以分散在存储中。
I can't say about exact format of Quake3, but there are several approaches to do what you need:
Each of those approaches has it's own strengths and weaknesses.
Our SolFS product is an example of virtual file system mentioned above. It was designed for tasks similar to yours.
Archives and some compound file implementations usually have linear sequential structure - the files are written one by one with some directory at the beginning or at the end of file.
Some compound file implementations, databases and virtual file system have page-based structure ("page" is similar to sector or cluster in FAT or NTFS) where files can be scattered across the storage.