一个简单的帧动作
最终，我采用了一个小技巧。导出程序会读取每一帧的ActionScript，然后用一堆正则表达式将其替换成C 。例如，crate.lid.play 会转换成 crate->lid->play; 。这两种语言在语法上非常相似，所以对于大部分简单的帧脚本来说，这种方式的效果很好，但依然会产生不少错误的代码，这些就只能手工重写了。
将所有的帧脚本转换成C 之后，就可以在编译时将其提取出来，变成每个符号的Node子类中的方法。同时还会生成一个负责分发的方法，负责在正确的时机调用这些方法。这个分发方法大致如下：
void tick override {switch (currentFrame) {case 1: _frame_1; break;case 45: _frame_45; break;case 200: _frame_200; break;}}
我想说明的最后一点是，最后生成的脚本是静态类型的，这一点很好，因为ActionScript本身并没有类型。而导出程序生成的游戏对象大致如下：
struct BigCrate: Node {BigCrateLid *lid { return (BigCrateLid *)getChild("lid"); }BigCrateLabel *label { return (BigCrateLabel *)getChild("label"); }void swingOpen { ... }void snapShut { ... }void burnAway { ... }};
所以，虽然底层依然是一大堆字符串查找，但这一层类型安全能够防止在错误的对象上调用错误的方法，避免了一大堆在动态类型语言中由于输入错误而导致的烦人的bug。
有过将旧媒体文件转成新格式经验的人对此应该不陌生。原来的游戏在浏览器上运行，根本没有考虑到全屏运行，所以长宽比是随意选取的。每个游戏都不一样，但大致都在3:2左右。
现在最常见的长宽比是16:9，一些笔记本上也有16:10的长宽比。我希望游戏能在这两种长宽比上正常运行，不会出现黑条，也不会拉伸图像。唯一的做法就是将原图切掉一部分，或加上一部分。
所以，我在每个游戏上画了两个矩形，一个是16:9，一个是16:10。然后游戏会根据屏幕分辨率计算矩形大小，然后用计算出的矩形作为相机的视图边界。只要所有重要的游戏元素都在这两个矩形的相交部分，且相交部分的边界不会超出场景边缘，就没问题。
16:10和16:9的矩形框。原始比例为3:2
唯一的难题是让场景本身适应额外的宽度，这需要重新绘制许多图形并重新排列，以适应新的长宽比。尽管有一点痛苦，但最后还是搞定了。
经过一番测试后，我发现Flash的阿尔法混合和颜色变换不是在线性空间内进行，而是在感知空间内进行的。从数学角度而言这样做是否正确还有待商榷，但我能理解为什么，因为许多绘画程序都是这样做的，它们希望能按照人们期待的方式工作，而不会考虑那些不懂商业的数学家的想法。但我还是要说，这样做是错误的！这样会导致抗锯齿等功能出现问题。
在对向量图进行光栅化时，你需要产生抗锯齿的输出，此时光栅化程序会产生一些阿尔法值，叫做“覆盖值”，意思是，如果某个像素在向量图中被盖住了一半，那么该像素的alpha值就是0.5。
但在Flash中，alpha等于0.5的意思是说它的颜色介于前景色和背景色之间的一半。
这两者完全不一样！
在不透明的黑色像素上绘制一个半覆盖的白色像素，其结果不应该是50%的灰色。光的原理并非如此，向量图的栅格化也不是这样工作的。（没有背景色，栅格化过程做不到“该像素的颜色应该位于前景色和背景色之间的 x%”。）
