MPEG for Allegro 再研究


这两天要期末烤了,云风经常逃课泡机房的,恐怕要挂彩. 记得上次我谈到那个 Allegro 的 MPEG 支持库吗? 昨天等着 上传主页也够无聊的,结果兴起,和作者通起 E-mail 侃起来. My English is too pool! 可怜的云风... 不过聊的倒也高兴, 不知道看我的英文的那位是怎么受折磨的;)

OK. 切入正题. 我们谈到这个程序的速度, 怎么慢的不能忍受? 晚上我就回去研究了. (又一个复习计划泡汤了) 难道是 Allegro 的速度比不上 DirectX? No. 我作了个小测试, 播放我制作的一段 MPEG (从VCD 中截出来的) 是 2585 的时间单位. 原来的写屏部分占了 425, 而我将愚蠢的函数画点的方法换为直接 movedata() 行传送后, 这个部分只占了 75. Allegro is excellent! 而 Huffman 解码的部分也只有 585 (当然这个也不够快, 我估计应该能达到 400 以下) 余下的部分消耗了大量的时间. 看来金山影霸最早的广告宣称只用 7 条语句完成向 RGB 的转换, 的确值得作者骄傲. 我终于也体会了. 当然这剩下的 1575 的时间单位 也不完全是干相当于那 7 条语句的事的.

通过分析程序, 我了解的速度的关键. 有两个决定速度的二重循环里竟然使用了 大量的条件表达式,仅仅是为了处理循环头尾处的特殊情况@#$%^&*! 我花了一个晚上进行了循环展开工作,剔除了循环中的所有判断.你猜怎样? 速度竟然从最原来的版本的 2235 提高到了 1600 左右. 了不起的优化;-)

这次优化程序给我的启发不小,以前我是很怕看别人写的复杂冗长的程序的. 有了这次的经验,以后我有信心去分析像 Doom 的源码这种东东了. 日后大家可以从我这学到不少新技术,而不用费力读那些源码了:D 不过我建议朋友你也学着读些老外们公布的源码吧, 对自己是一个很好的提高. 其二, 程序设计中的优化技术真的很重要, 我一向注重它,可以前总是有人说我钻牛角尖,自己有时也怀疑自己的做法了, 现在却坚定了我的看法,计算机的每一个比特,每一个 CPU 时间片都是最宝贵的资源. 请不要嘲笑我还停留在 386 时代,即使是现在的 Pentium II, 如果我们程序员不去注意这些,带给我们的都是灾难. 等着 Intel 的 P9 吧...

btw,我的程序已经并入那个 MPEG 包, 我的名字也将幸运的写进软件文档. 大家等着我们即将推出的下个版本吧, 速度将有一个飞跃, 我也可能会完成一个 DOS 下播放 VCD 的软件. 就聊到这里了, 明天见 :-)

云风 草书于1998.6.23