随笔 - 119  文章 - 290  trackbacks - 0

博客搬家了哦,请移步
叫我abc

常用链接

留言簿(12)

随笔分类

我的博客

搜索

  •  

积分与排名

  • 积分 - 299330
  • 排名 - 84

最新评论

阅读排行榜

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

posted on 2007-11-27 21:18 LOGOS 阅读(1384) 评论(2)  编辑 收藏 引用 所属分类: 《GAME PROGRAMMING GEMS6》读书笔记

FeedBack:
# re: 《GAME PROGRAMMING GEMS6》读书笔记-3 2007-11-29 22:30 helixapp
对字符串相似的有些兴趣 不过好像效率一般啊  回复  更多评论
  
# re: 《GAME PROGRAMMING GEMS6》读书笔记-3 2007-11-30 10:42 LOGOS
@helixapp
应该说效率很差,不过这个做法只是为了更方便的排查错误的,而并非用于避免错误。  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理