单片数据文件的原因

• 查找速度 hash( normalized_filename ) -> [ offset, size ] 非常 迅速地。我们还可以将这个索引保存在RAM中,有可能将它与其他索引表交织在一起,等等。
• .arc ,或者我们可以将一个文件名列表、一个文件名哈希列表,或者只是一个[offset,size]对列表存储在某处--甚至可以作为存档中的一个文件。这通常比FS上的目录遍历更快。)
• 元数据 :我们很容易将任何需要的文件元数据塞进。例如,“size”字段中的单个位指示文件是否已压缩(如果已压缩,则有一个标头,其中包含有关如何解压缩的详细信息)。如果我们提前对文件的结构有足够的了解,我们甚至可以对文件的各个部分进行不同的压缩(我们这样做是为了sprite存档)。
• 大小 :我们使用的其中一个设备具有“文件大小必须是X的倍数”要求,其中X与我们的一些文件相比是大的。例如,我们的一些lua脚本在编译时只有几百字节;每个.luc文件占用的额外开销加起来很快。
• :另一方面,有时我们 希望 做

但这些都是平凡的原因。更有趣的东西:

每个 .弧 在列表中注册,并尝试打开一个文件,以便在弧中查找。我们先搜索RAM归档文件,然后搜索设备FS上的归档文件,然后搜索实际的设备FS。这给了我们很大的灵活性:

• :在任何时候,我们都可以将一个新的文件或归档文件流式传输到有问题的机器上(通过网络或类似的方式),并将其显示为“逻辑”文件系统的一部分;当实际的FS驻留在ROM或CD上时,这是非常好的,它允许我们比其他方法更快地迭代。
• (厄运来了。) .wad 系统就是上面的一个例子,它允许修改者更容易地覆盖游戏中内置的资源和脚本。)
• 无潜在财务报表的可能性 :可以使用 bin2obj 将整个弧直接嵌入到可执行文件中( .rodata
• 组织和装卸 :由于我们可以在任何时候加载、卸载和覆盖文件系统的虚拟“片段”,因此我们可以在任何给定的时间通过使FS中的文件数量非常少来实现一些性能技巧。我们还可以指定将整个归档文件加载到内存、索引表和数据中;我们的文件加载代码非常聪明,可以知道如果文件已经在内存中,它不需要做任何事情来读取它,只需要移动指针。一些更高级别的代码实际上可以检测到文件在ram中,并直接请求可能已经看起来像结构的指针。
• 便携性 :我们只需要弄清楚如何在每个新设备上获取一些文件,然后FS代码的其余部分就差不多了。=)我们偶尔会更改一下工具输出(出于对齐的原因),但大多数处理都保持不变。
• :使用更智能的归档,例如我们的sprite归档,我们可以(并且可以)消除重复数据。如果“跳跃”动画的第五帧和“踢”的第三帧是相同的,我们可以分开文件,只存储该帧的一个副本。我们可以对整个文件做同样的处理。

subdir.arc ,然后把它粘在母版上 game.arc 压缩的。当需要dir时(比如调用opendir),我们将整个subdir.arc解压到RAM中,将其添加到文件系统中,然后超级快速地遍历它。

它能够在几个小时内将这样的东西组合在一起,并减轻跨系统移植的痛苦,这使得这样的东西是值得的。

文件系统在必要时会派上用场 修改 文件,因为它们比任何简单的自行开发的解决方案更好地处理文件大小的变化。然而,对于恒定的游戏数据来说,情况肯定不是这样。

然而,在Windows上,我相信这要困难得多,它看起来就像一个目录“不管发生什么”(我相信聪明的人已经找到了一个解决方案,可以让浏览器将某些目录看作一个文件,但这并不常见)。

如果我是游戏开发者的话,我会喜欢个人档案。再说一次,我会像为Mac写东西一样使用bundle;-)

干杯

尼克

正如doublep所建议的,文件在光盘上占用的空间比它们所需要的要多。所以存档可以节省空间。10k文件(任何大小)在打包到归档文件中时可以节省20MB的空间。现在的空间不大,但仍然很小。

或许还有另一个我从未想过的原因:D。