第拾叁章 焦头烂额 (第3/6页)

们看走眼的时候也会有。”

    当然，这种粗糙拙劣的证明立刻就会被一眼识破。在数学家们善意的提醒之后，范含恶意的毫无痕迹的提醒数学家们，只要把所有的可能性补全，就可以真正的证明之。

    功夫不负有心人，回过味来的数学家们很快就真正的证明了四色定理。

    于是，“FOR”在数学圈内名声大振。本门的师哥师弟师姐师妹们如同吟游诗人那样传颂着从前辈高人那里听说到的“天真而热情的外行，作家范含”和“严格并较真的领导，企业家奥尔森”的传奇故事。

    范含还没来得及陶醉，一个坏消息传来，FEEE的“Squares”系列卖到日本的机器出了故障。奇怪的是，明明是同样的机器，在美国就是一点事儿也没有。

    -------

    （大家猜一猜，什么故障？提示：和美、日两国的环境有关，和种族主义无关。）

    -------

    本来也没什么大事，就是有几个日本人玩经典俄罗斯方块玩着玩着发现分数又从零开始算起了。那几个鬼子都是高手，都是玩到无数关之后才出现。

    上溢，再简单没有的问题，FEEE的工作人员接到投诉之后立刻就判断出来了。现在的问题是要找到什么原因，美国的机器就是一点事也没有。这点小事就耽误了一个星期，总部的一帮大白小白们死活找不出来，最后只好往上报。正好范含从各大院校的巡回演出中脱身，回到洛杉矶之后，立刻就收到了这份报告。

    仔细看看了相关资料，范含大怒：“Ｘ的！这帮笨蛋！”

    理由再简单不过了，两国的电源频率不同。美国是60Hz，日本大部分地区是50Hz。

    最初设计机器的时候为了降低成本，计时部分直接用模拟电路实现，这一点范含并没有意见。

    实际上，几乎所有传统视频应用都依赖于电源的频率。范含以前玩视频处理的时候，就牢牢的记住了美国片子每秒钟三十帧，日本片子每秒钟二十五帧。尤其是数字制作的片子，比如动画片。所以并不奇怪为什么自己总是感觉美国片画面更流畅，百分之二十的差距，是个人就能看得出来。当然了，传统电影例外，每秒钟二十四帧的规矩是从胶片时代传下来的。

    具体到FEEE的机型，为了计时，电路设计就决定了每六十拍算作一秒钟。

    经典的俄罗斯方块间隔是从一秒钟开始，每六十拍方块下落一格。每过一关，间隔缩短零点一秒，就是六拍。过了十关之后，间隔只有六拍了，这时候看见方块就是呼呼的往下掉。如果还没死，接下来就是两拍两拍的减少，减到零，游戏自然结束。整个游戏最多有十二关，没有第十三关。这样也好，照顾到了老美的宗教迷信。

    游戏区间和Emacs的tetris游戏完全一样，10格宽，20格高。每消掉100行算过一关，这就是100*10=1000个方块。剩下的全填满也不过是19*9=171个方块。一共1171个方块，折合1171/4=292个构件。按照规则，每出现一个构件，就有1分的生存加分，每关最多292分。消掉的那100行按照最乐观的估计是四行四行的清除，一共有25次，每次可得到2的4次方等于16分，每关最多是25*16=400分。这样一来，每关最高得分是292 400=692分。实际上做不到，因为想要四行四行的消，最后只能剩下16行，生存加分最多282分，理论最高分682分。

    如此说来，就算游戏“通关”，最高撑死了也不过是682*12=8232分罢了。

    设计计分器的时候，由于字长是4位，采用了四个字，共16位。不过，其中一位用来表示分数属于左侧还是右侧的玩家（就是1P或2P），还有一位用来表示分数是单人游戏还是双人对战。如此看来，还剩下14位。但是，开发之初，所有设计都是画在纸上的。谁敢肯定真干起来没有别的信息需要标志位？为了保险起见，还是保留了一位备用。这种做法无可厚非，就算范含亲自参与设计，也会这么干的。在软件开发领域没有什么人一上来就敢把所有的位置都用满。几乎所有的SDK文档里面都有那么一些常量标了不少“Reversed”以待将来使用的位，往往是直到淘汰也还没派上用场。

    最终的分数是用13个二进制位表示……难道宗教迷信真的有点意思……最多可以累加到2的13次方减1等于8191分。

    这个数字比起理论最高分仅仅少了一点点而已。几乎所有开发人员都同意，不会有什么人能够做到使计分器上溢。于是，这个设计就这么定了。

    如果事情仅仅如此，恐怕就不会出问题。

    遗憾的是，同时还发生了另外几件事。

    第一件，游戏摇杆和按钮的输入是有缓冲区的。当初是为了在来不及相应控制信息的情况下暂时保存用户cao作，以待处理器空闲时逐步按照顺序处理。只不过编码的时候草率了一些，没有及时清空缓冲区。就是说，在一个构件已经落下，另一个构件还没出来的时候进行输入，下一个构件出现后就会按照刚才的输入进行动作。

    消息队列的设计在软件里面司空见惯，范含在这个地方犯了一个想当然的错误。可能是平时模拟器玩惯了，把摇杆的消息和按钮的消息统一起来当作“KeyDown”处理。实际上，摇杆作为指点设备，应该像鼠标那样。在Windows里面，大部分消息都是一条当作一条，直接放进队列。但是“MouseMove”例外，仅仅是做一个标记，表示当前鼠标正在移动。对于这种极为频繁的消息，这么处理是相当妥帖的。否则的话，只要鼠标划过屏幕，队列就会被填满。就是因为这样，范含当初在向德州仪器交待需求的时候说的就是“压住摇杆不动就要连续不断地发出信号”。

    第二件，Emacs的俄罗斯方块游戏是在按“下”的时候直接将构件落到底部。范含写源代码的时候照猫画虎，FEEE的工作人员当然不会擅自改动，说不定都以为这个游戏本来就是这样的。不像后来红白机上那样，按住“下”不松开是加快下落速度，松开后速度恢复正常。平心而论，后来的这个设计更是合理，cao作性更强。但是在现在，范含和其他FEEE的人员都是闭门造车，发布之前就没有征求过玩家的意见。用户和程序员看待问题的角度是不一样的，程序员怎么看自己的作品怎么觉得顺眼，用户则不然。像软件开发中的“用户体验”，“人性化”这种东西，必须向闲杂人等们收集意见。于是，只要一个“下”，构件就会直接到达底部，不管中间有多长。

    虽然这一点没考虑到，但是范含考虑到了另外一点“人