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

首先是GENERAL PROGRAMMING SECTION。

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

當字符ID拼寫錯誤后，就是利用這個算法找出最匹配的ID進行替代。
這個算法還是蠻消耗的，因此一般是在debug版中使用，和不使用該算法的系統比起來，這個能在log中提供一份你實際上想拼寫的字符串的信息，便于更高效的查錯。

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

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