程序员调代码访谈:James Hague

『程序员调代码访谈』是 Karim Hamidou 发起的一个程序员访谈系列,受访者分享他们遇到的最难/最有意思的Bug,以及如何解决。

本文的受访者是 James Hague,一位程序员,游戏设计师,也是 Programming in the 21st Century 的博主。


你是谁

我是一个早在8位机(红白机游戏机)时期就学习编程的游戏设计师,所以我有能力实现自己的想法。最终我意识到自己因为编程的原因而在编程这条道路上走得太远,于是转变角色成为一个全职游戏设计师。但是我仍然喜欢为自己的项目写代码,在我的大脑没有被各种技术完全占据的时候,使得我可以发掘方法来致力于开发过程中最有创作性的部分,我从2007开始便一直在 Programming in the 21st Century  上发表博客,这是我的twitter@dadgumjames

你解决过的有意思的bug有什么

在PlayStation 2(PS2)的游戏Summoner 2有两次编译:开发时期编译,即每个文件分开存储,随后是打包编译,即相关的文件都会被压缩到一个文件中。每个压缩文件在前端有一个小型的目录,之后是那些被压缩的文件内容。压缩文件中的每个单个文件都会被填充到2048个字节,因为那是一个DVD扇区的容量。DVD比硬盘速度慢很多,所以设计压缩文件的初衷就是避免在顺序读取数据的时候遇到任何寻址问题。

通常情况下每个人都能够进行开发时期编译因为这一步比较简单,但是偶然地我会编译了一版打包文件来确认文件没有问题。大多数情况下是没有问题的。

然后有一天游戏在读取压缩文件的时候崩溃了。我需要查看很多数据来确保没有犯任何错误,所以从代码版本管理器上下载了所有的代码,编译,一切运行良好!直到几周之后有一个不同的压缩文件出现了使游戏崩溃的问题。同样的结果:当我尝试用新的数据重现这个问题的时候,问题就消失了。

最终我写了一个Perl工具来验证压缩文件的集成问题。下一次当这个神秘的崩溃问题再次出现时,我运行了这个工具,发现目录与实际数据到中途的时候已经没有对齐了。更奇怪的是,在这个问题中,被压缩的文件中有一个大小恰好就是2048
字节,用不到额外的填充。

问题就出在用来填充的代码上。算法类似于如下

如果被压缩的某一个文件大小是2000,那么padded_size返回2048,这是正确的。但是如果size已经是2048的倍数,那么返回4096,所以这个文件就还需要另外一个扇区。

我把方法换成了如下的代码

有什么要补充的?

我把这个问题作为面试问题使用了一段时间,但是疲惫于解释为什么要问这样琐碎的问题。但是,最起码在我问过的人中有一半写出了与第一版填充代码相似的代码,没有意识到这个边界问题。

2 收藏 1 评论

关于作者:SunRobin

立志成为代码中的西伯利亚狼。(新浪微博:@老码农的自留地)(CSDN博客:@会写代码的大叔)微博:CSDN: 个人主页 · 我的文章 · 10

相关文章

可能感兴趣的话题



直接登录
最新评论
  • int padded_size(int size)
    {
    return size % 2048 == 0 ? size : size + (2048 - (size % 2048));
    }

    效率最高的是这个

    (size + 2047) & ~2047;

跳到底部
返回顶部