上午写了两个类，实现了自定义资源文件，数据流的存取

6spring

呵呵，问题就是在IO开销大这方面，游戏里图片、模型又多又大，资源包往往也是大的惊人，每次花几十分钟打包，一次二次还好，经常弄，有点受不了。。。。

自己曾经考虑过也做个打包系统，基本思路是引入磁盘的索引式文件结构，内部数据以块为单位（例如4K），块可用于储存索引信息或数据信息，预留超级块保存管理信息，例如盘符、空闲快索引信息头、文件索引信息头（基本就是把OS中的磁盘管理部分模拟过来）。这样更新、添加、删除文件等都可以通过改变索引信息及部分数据块完成，也可在必要时做一次“磁盘整理”。但是搞来搞去，发现有点性价比太低，一时也不急，就放弃了。

题外话：关于内部数据压缩这点上，很有意思，游戏的图片文件好多是基本不用再压缩的格式，有不少拿zlib压缩，反而会增大（尤其是gif、png）

prefetchnta

只要在读包内文件前 check 一下磁盘上有无这个文件即可
制作时都用文件，发行时弄个bat打包
要管理方便的话，可用zip不压缩，然后加到自己的包里

tonykee

也对哦，那我应该加个参数，表明raw需不需要压缩
开发的时候不打包
发行的时候再打包
打包的时候可选择压缩和不压缩

程序的api加入检测或设定机制。

楼上几位朋友给了我很大的帮助，谢谢各位

funcman

游戏里，往包里添、改文件是什么情况？

oz01

6spring: Re:上午写了两个类，实现了自定义资源文件，数据流的存取，一个字爽

呵呵，问题就是在IO开销大这方面，游戏里图片、模型又多又大，资源包往往也是大的惊人，每次花几十分钟打包...

gif是lz78
png是deflate也就是zlib
这两种图片你再压缩免不了要变大的.............
绝大多数音频视频
pc上通用的绝大多数图片格式都不用再压缩
需要压缩的主要是BMP和TGA
不过这两种图片有些也适用RLE压缩

oz01

关与包内文件修改
貌似国外一些游戏公司都使用dummy
每隔一段空间插入一段dummy数据
在处理文件包的时候
如果新文件比原文件小
那么包就没什么大改动
如果比原文件大
那么只需要调整几个dummy以内的数据即可
最后游戏发布的时候重组一次包

tonykee

我这两天也思考了一番
其实如果要做的比较完美一点,可以借鉴oracle数据库里面的分页索引结构,就是把存储空间分成很多的page
把page作为最小的存储单位可以定为4k一个page,然后专门创建一个分区索引区,表明一段数据区对应哪些page,要删除数据的时候,只需要表明那几个page不再使用,可以重写,适当的时候可以重整空间,把标识为已经删除的page给搬移到文件的最后,类似于defrag的效果,这样不管是读还是写,效率都是很高的.文件空间能更合理的布局

不过要做到上面这些似乎这也算一个大工程了.目前暂时也不打算这样去做,这基本就相当于实现了一个文件数据库了.

6spring

回OZ，前面回的那帖，我只是想说明，pak系统自带压缩对于游戏应用并不是一个很好选择，最浅显的莫过于图片数据。

回LS，这个确切的说应该是模仿磁盘文件系统（Windows下磁盘文件默认块即为4K）。在大学期间，曾经做过一个模仿FAT格式的Mini File System，对这个还是很有好感的，呵呵。对了，这些东西很容易在开源的OS（比如linux）中找到现成的代码。

congy

tonykee: Re:上午写了两个类，实现了自定义资源文件，数据流的存取，一个字爽

我这两天也思考了一番
其实如果要做的比较完美一点,可以借鉴oracle数据库里面的分页索引结构,就是把存储空...

如果做了这些才称得上是包文件系统.
也不必拘泥于 4k。自己实现的话就要对包空间作管理，在增加、修改、删除数据时标示出空间的属性，根据这些属性的出最优化的顺序来调整数据在包中的存储位置。另外对于压缩数据要根据情况，顶点和动画可以压缩，更重要的是加密。这两个数据属性也要在包中存储，再度取得时候根据压缩、加密的属性来动态选择使用哪种压缩和解密算法。

tonykee

题外话，对于加密算法，各位一般怎么抉择？