我在偶然看到某人推荐的一篇，《森林故事，以及干脆面军团考证》中，发现一些较为精细图片的水印指向一个网址，arkive.org，寻根至此发现这是一个专门收集，介绍濒危物种的公益性质网站。对物种的描述非常全面，并配备有大量的图片和视频资料，令人心生敬仰，并想为此作点什么，（写博记录和传播也是一种帮助吧）。
浏览中，遇到鸟类分类下的一种名字很土著的胖鸟，唤做Kakapo,于是发了搜索病，试译部分内容如下。
一日不复药，血压归旧高，诚如二弟所言，高血压是一辈子的事。继续完成剩余译文。
扁平化Sprite（Flattened Sprites）
为了追求最小化的状态变更，你已经做了一大堆事以期你的游戏获得性能提升。然而Starling仍然需要遍历你所有的对象，检查它们的状态，并且把它们的数据提交到GPU——这可是在每一帧都发生的事啊！（好恐怖啊！）
别慌，我们下一步就来搞定这个问题。如果在你的游戏中的某个部分的几何图案处于静态，不发生（或者很少发生）变化，可以在这个Sprite上调用flatten方法。Starling将会预处理它和它的子对象数据并提交给GPU。在接下来的帧调用中，它将被正常的绘制，不触发任何CPU处理，也不需要在上传它的数据给GPU。
这是一个非常棒的特性，这潜在地大量减轻了GPU的负担。但是要注意的是即便扁平化的sprite们被从状态变更的苦难中隔离了出来：如果被扁平化的Sprite中包含有不同渲染状态的子对象，它仍然是会被多步骤的绘制的。
今天来翻译第二部分。
针对Starling的专门建议
把状态变更缩减至最小
如你所知，Starling使用Stage3D做所有的可见对象渲染。这意味着所有的绘制都是由GPU完成的。
目前，Starling每次提交一个四边形数据，一个接一个地向GPU提交，一个接一个地绘制。实际上，这也是最初版本的Starling的工作办法，所以可以通过一次向GPU提交大批量的数据进行绘制的办法，来获得最佳性能。
这也是为什么新的Starling版本在每次向GPU提交之前尽量积存较多的四边形数据。不过，它只能批量提交具有相似特性的四边形。每当遇到一个状态发生变化的四边形时，一个“状态变更”就发生了，之前的批量数据们就被提交绘制了。
Starling的性能优化
尽管Starling仿造了Flash显示列表的经典结构，但是在这表象的背后却蕴含着巨大的不同。因此，想要使程序达到最佳的性能，你首先应该了解其架构中的一些关键性概念。下面是一个最佳实践列表，你可以按照这个顺序实践来使你的游戏运行得尽可能地快，哦耶。
与标准AS3相关的建议
永远要以发布版本(release build)作为性能比照的依据
为了响应来自TexturePacker作者大方赠送的PhysicsEditor（以下简称PE）的license，我花了一点时间写了一个小东西，创建的过程记录在此，以备后用。
某日在使用之前提到的TexturePacker的软件时，发现我的试用期已经过了，Mac版本还好会弹出一个对话框提示过期，Windows版本会直接把你素材中较大的图形资源加上红色滤镜，并用小字体遍布其上，反复念叨着（你丫已经过期了你知道么）。
在搜寻key的过程中，忽然发现一位老兄提到可以申请一个免费的开发者授权，他申请的时候是3.1.0版本，抱着试试看的态度，我就先买了一个疗程的，准备吃吃看填写了一份申请表单，申请地址在此，
Request a free license for Code’n’Web tools
我不知道这个免费的申请过程有多久，不过我确实认为这是个行之有效的开发软件推销行为，我也很乐意写一篇博客转述这样一个优秀的图片资源打包软件。
我的朋友Winnie去了神奈川玩，她和她的老公一脸憨笑地在OP中樱木向晴子挥手的地方合影，嗯……项目嫉妒恨满腹！
大弟弟去了一次韩国玩（我当然不想提他房子都装修好了老婆却和他吹了这件事了，说不定就是这样才一下子整个世界都开朗起来了呢！），6天，然后就开始在微博空间里大谈韩国文化了，文化！这是多么大的一个命题啊，我觉得你是词汇量不足只能想起文化这个词吧？
近期老大开始研究各种消除类游戏的界面设计，发现其中一个细节是，我们的界面风格无论怎么看都都有一种硬邦邦的感觉，过多尖锐的直角很容易令人紧张，不利于治愈人心，所以我们开始尝试改变，其中一点就是，如何让尖锐的边缘变得圆润，涉及到要绘制一个连续的圆形边缘效果，两个放在一起对比一下区别还是比较明显的。
有一个令许多AntiFlasher喜大普奔的消息，就是Adobe今日宣布了开源的Snap.svg API，我马上屁颠儿屁颠儿的跑去看。