本人正在準備做一個游戲引擎（你就當我準備產(chǎn)生垃圾好了~呵呵！），準備寫文檔，就順便把這篇文章寫出來了，初次發(fā)稿，寫得可能不是很好，請多多包涵~謝謝！~~
資源打包就是將一些零碎資源（如圖片，音樂文件）。打包的好處有哪些呢？
1、減少碎片。因為WINDOWS的文件管理系統(tǒng)的原因，將這些資源按原樣放在硬盤里，會產(chǎn)生“碎片”。比如1個字節(jié)的文件，占用的空間就高達8KB。這樣，資源可以說“膨脹”了。
2、安全。將這些數(shù)據(jù)集合起來打包的話，就可以隱藏這些文件，讓用戶不能修改（如果某位高手破解了文件結(jié)構(gòu)并提取出來了的話你當我沒說~）
我想到的只有這些，如果哪位大蝦認為還可以補充的，請聯(lián)系我：）
好了！我們現(xiàn)在來構(gòu)造一個結(jié)構(gòu)來儲存這些文件吧！在這里因為我準備寫的是只儲存圖形的游戲引擎，所以我想到的只是圖片的儲存，其他文件的儲存，這里沒有涉及。
我們先構(gòu)造一個文件頭，這個文件頭描述了一些基本的信息，有長度，文件版本，壓縮類型，還有儲存的圖片總數(shù)。現(xiàn)在詳細的說一下，長度就不用說了吧，文件頭的大小。文件版本是給打包工具看的東東，游戲引擎里也可以使用，根據(jù)版本來用不同的方法打開文件（不同的結(jié)構(gòu)，或者其他的）。壓縮類型是一個以備擴展用的東東，根據(jù)標識來使用不同的壓縮方法解壓縮，在這里可以選一個速度和容量折中的壓縮方法。圖片總數(shù)說的不是單個圖片的總數(shù)，而是靜態(tài)圖片和動態(tài)圖片的總數(shù)，靜態(tài)圖片可以理解成一個圖片，動態(tài)圖片就是一系列靜態(tài)圖片的集合，這個在后面會說到。講一個文件頭就說了這么多話。我講得是太詳細了還是太水了？
struct FileHeader
{
unsigned long headsize; //文件頭長度
int Version; //文件版本
int Compress; //壓縮類型
int AllNumber; //圖片總數(shù)
}
然后緊跟一個結(jié)構(gòu)數(shù)組，這個結(jié)構(gòu)描述了每個圖片的起始偏移量，這個偏移量是以文件頭的長度+索引結(jié)構(gòu)數(shù)組的長度+1為基址的，還描述了圖片的幀數(shù)，為1則表示為靜態(tài)圖片，大于1則表示動態(tài)圖片（動態(tài)圖片很有用處，比如海面，被風(fēng)吹動的樹，這些就可以很容易的表示出來）
struct PicIndex
{
int offset; //圖片偏移量
unsigned long PicSize //圖片長度（如果是多幀的則代表這個圖片集的總共長度）
int nFrameNumber; //圖片幀數(shù)
unsigned long nFrameSize[nFrameNumber]; //每一幀的偏移量，這里的偏移量就是基址+offset+這一個偏移量。。#··%…！天書？
//當然上面這個數(shù)組定義編譯時不能這樣寫
}
PicIndex結(jié)構(gòu)是一個數(shù)組，它的下標為AllNumber個。例如：
PicIndex Index[AllNumber];
然后剩下的就是一些數(shù)據(jù)了，這些數(shù)據(jù)已經(jīng)被壓縮了，壓縮方式通過文件頭的AllNumber變量來獲得。
下標n其實就是AllNumber，這里為了省空間：）
值得注意的是后面的壓縮數(shù)據(jù)不是整塊壓縮的，而是單個圖片的壓縮，然后放在一起而已，我這樣做是為了讀取方便，就不用讀取一個數(shù)據(jù)還要把整個文件再解壓縮一道了，這樣壓縮率可能也會降低，不知道是否還有更好的辦法，如果有，請聯(lián)系我~謝謝！
除了我寫的這種結(jié)構(gòu)方式來儲存文件以外，還有其他的實現(xiàn)方案，但是我覺得這個好一點。
代碼我剛寫一半，還不完全，所以這里就不放上來了。
我的QQ：393277421
我再說一句最重要的話：有空常聯(lián)系~~~~~~~~