最近阅读了《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时间，不过这又增加了解压时间。