懒人求个算法……

rednaxela

考虑到通配在游戏里用到的机会应该不会太多，我想还是遍历算了，实在是懒……

嗯我觉得这样是合理的。除非做profile的时候发现那里特别耗时间，不然没必要过早为优化而做复杂的设计。

"archive"本身就可以说是个微型的文件系统——标准的archive构成是：
signature/multiple signature/checksum
file count
index entry - filename/offset/length/flags/specialParams per entry
file contents

于是索引的部分肯定得存在（虽然archive的索引未必一定在archive内；嘛，一般是在里面的）

然后将实际的文件系统与这些archive统一起来的方式，就是建立一个在更高层次的virtual file system，将所有“资源”以统一的方式来访问。例如说吉里吉里2所使用的Storage系统就是这样的一种设计/实现，通过类似"file://"这样的protocol来访问文件，假如是实际文件就file://./pathname/filename.ext，假如是archive里的文件就file://./pathname/archivename.ext>subpath/filename.ext。FlipCode的例子做的是几乎一样的事情，设计了一种基于实际文件系统的虚拟文件系统，以统一的方式提供了一般的文件操作，如读、写、查找等。它的代码比吉里吉里2的好读多了，虽然老了点不过还是值得参考的。

说起来，特定在Windows上有shlwapi.dll，可以用shlwapi.h来使用里面的功能，有大量的Path函数可用，可以考虑下。

==========================================

那个fnmatch好眼熟……我肯定在之前写那个破解/汉化ef的工具里也用过它。回头看看是不是的……

lw

海量文件…………偶只是纯粹的线性查找，自己只是給自己做的图片打包而已。。。所以没有多少文件啊－ －

john_he

引用第10楼rednaxela于2007-12-01 01:20发表的  :

嗯我觉得这样是合理的。除非做profile的时候发现那里特别耗时间，不然没必要过早为优化而做复杂的设计。

"archive"本身就可以说是个微型的文件系统——标准的archive构成是：
signature/multiple signature/checksum
.......

我的那个不打算用protocol这么高级的东西……只是把Archive当成一个目录，例如Data.pak里的texture.png就映射成Data/texture.png，有重名的话先搜索到哪个就返回哪个……嘛，这样比较直观一点嘛。

至于具体的接口/实现基本上定下来了，就是Ogre里的那种模式……
貌似HGE那个实现更简单，不过扩展性比较差还是算了……

lw

这里追加一个LINK算是续好了……
http://bbs.rpgchina.com/read-htm-tid-31235-toread-1.html