最近閱讀了《GAME PROGRAMMING GEMS6》，頗有收獲，以筆記之。

首先是GENERAL PROGRAMMING SECTION。

1.6 Closest-String Matching Algorithm
這章描述的是計(jì)算兩個(gè)字符串相似度的算法。
為什么要計(jì)算兩個(gè)字符串的相似度呢？在以字符串為ID的系統(tǒng)下，常常會(huì)出現(xiàn)粗心拼寫(xiě)錯(cuò)誤的問(wèn)題，這時(shí)候程序的運(yùn)行是為定義的，也比較難查錯(cuò)。這個(gè)問(wèn)題被稱為String-Based ID Lookups。
通過(guò)計(jì)算字符串的相似度，可以在拼寫(xiě)錯(cuò)誤的時(shí)候從ID集合中找到一個(gè)最近似的ID作為代替，這樣程序能繼續(xù)執(zhí)行，同時(shí)把這個(gè)拼寫(xiě)錯(cuò)誤的事件log出來(lái)。
算法很簡(jiǎn)單：
(a)取兩個(gè)字符串的最大長(zhǎng)度 L
(b)由第一個(gè)字符開(kāi)始逐個(gè)比較兩個(gè)字符串的字符，如果字符相同則相似度加（1/L），如果在全部轉(zhuǎn)換成小寫(xiě)后相同則相似度加（0.9/L）。
(c)完全不匹配的話，則需要分別移動(dòng)兩個(gè)字符串的字符指針，直到找到下一個(gè)相同的字符對(duì)為止（大小寫(xiě)無(wú)關(guān)），同時(shí)要求這兩個(gè)字符串的字符指針偏移是最小的，即找到一個(gè)最優(yōu)的匹配位置。
(d)重復(fù)這個(gè)過(guò)程，直到字符串尾。

當(dāng)字符ID拼寫(xiě)錯(cuò)誤后，就是利用這個(gè)算法找出最匹配的ID進(jìn)行替代。
這個(gè)算法還是蠻消耗的，因此一般是在debug版中使用，和不使用該算法的系統(tǒng)比起來(lái)，這個(gè)能在log中提供一份你實(shí)際上想拼寫(xiě)的字符串的信息，便于更高效的查錯(cuò)。

1.9 Faster File Loading with Access-Based File Reordering
這篇文章討論的是加快游戲loading速度的問(wèn)題，提出的方法是基于文件的訪問(wèn)順序重新安排文件的位置。當(dāng)然，這是針對(duì)打包文件的優(yōu)化。
(a)How Access-Based File Reordering Works
方法也很簡(jiǎn)單：
(1)運(yùn)行游戲，通過(guò)ResourceMgr記錄出載入每個(gè)資源的順序和裝載時(shí)間，這份記錄保存到一個(gè)文件上。
(2)寫(xiě)一個(gè)工具，用來(lái)分析上面的文件，并生成一個(gè)相關(guān)資源的新順序的輸出文件。
(3)運(yùn)行打包工具，按照新順序重新打包資源。
(4)重復(fù)這個(gè)過(guò)程。

最后還介紹了其他一些好的方法
(b)General Loading Best-Practices
(1)Sequential Access
可以翻譯為串行訪問(wèn)吧？簡(jiǎn)單的說(shuō)，就是不要老把文件的讀寫(xiě)指針跳來(lái)跳去的，因?yàn)橛布?huì)緩存當(dāng)前指針下的內(nèi)容，指針跳來(lái)跳去的，它的付出就全浪費(fèi)了。所以，從頭讀到尾是最好的。
(2)Preprocess Your Data
打包的時(shí)候把數(shù)據(jù)轉(zhuǎn)換成二進(jìn)制格式，盡量是一進(jìn)內(nèi)存就能用的那種，不需要進(jìn)行分析和轉(zhuǎn)換。這樣就省卻了解析時(shí)間了。
(3)Cache File In Memory
暫時(shí)不使用的資源不用立即全部釋放，可以先放在資源銀行嘛。
(4)Data Compression
數(shù)據(jù)壓縮，減少尺寸也就減少了loading時(shí)間，不過(guò)這又增加了解壓時(shí)間。