原文：SwitchingColor Shader
翻译：dreamana.com
你有看过这个 Nissan Juke 的网站专题吗？我在偶然在 Away3D showcase 里发现这个 microsite 的。很棒的美术，优雅的程序。自从我玩过许多 shader 之后，我立刻就对这个不可思议的 shader 作品产生兴趣。尤其这个“颜色切换”特效（当你点击汽车有色的区域并选择一个新颜色的时候）引起了我的注意。花了几个钟头的修修补补之后我做了一个 shader 出来，看起来很像。看！就点击方块的任意地方，却换到一个随机颜色。
Have you already seen the Nissan Juke webspecial? I came across this microsite on the Away3D showcase. Great artwork, neat programming. As I was playing a lot with shaders, I was immediately interested in the incredible shaderwork that was done here. Especially the “color switching” effect (when you click on a colored area of the car and select a new color), caught my attention. After some hours of tinkering I came up with a shader, which looks quite the same. Have a look! Just click on the block anywhere, to switch to a random color.
自从制作了一套自用的 UI 组件集之后，使用过程中我发现仍然有各种不顺心的地方。可能思维被 Flash 传统的 UI 组件固化了。于是萌生出制作第二版的想法。
但，真的能突破吗？
首先，我打算弃用 MonoUI 这个名字，原因就是已经有一个叫 Mono 的东东了，很容易会被人误会我这个是 .Net 的 Mono…
那么新名字先放一边，如何改进才是麻烦事。使用 Flash 做 GUI，渲染方式现在只有 2 种选择：
- 传统 DisplayList
- Stage3D
考虑到日后项目的通用性，我觉得必然要选用 DisplayList。然而麻烦的根源也是这里：
DisplayList 的架构没办法改变。
- 不能通过继承 DisplayObject/DisplayObjectContainer/InteractiveObject 实现自己的显示对象
- 作为容器只能选择继承 Sprite
- Bitmap 不具备交互能力（不继承 InteractiveObject）
- 单纯使用 Graphics 或单纯使用 BitmapData 各有优劣（即使用全矢量或使用全位图都不是最优的办法）
- 涉及 AS3 Event 模型（AS3 事件模型也有各种不治之症），主要是鼠标交互方面
以上种种，导致使用 DisplayList 作为 UI 渲染方式的时候性能优化很有限。尤其是实现皮肤功能的时候，简化显示列表会变得困难，但想实现动态皮肤，又不得不利用更多显示层级来实现。
原文：Making ByteArray faster
作者：Romil Mittal
翻译：dreamana.com
FlasCC (之前叫 Alchemy) 生成的 ActionScript 字节码 (简称 .abc) 比起用 ActionScript 编译器实现的性能更好。除了因为用了更好的数据类型和指令之外，背后的一个主要原因是 FlasCC 使用了 domain memory，使其在内存缓冲区中读写速度更快。Flash 与 AIR Runtime 已经支持这些特殊的内存操作码去使用 domain memory 提高内存访问速度。
从 AIR 3.6 开始，ActionScript 编译器 2.0 (ASC2) 能够直接从 AS3 代码编译出这些快速内存操作码了（之前只能通过 FlasCC 实现）。
有限状态机
Ash 的组件控制方案出来了，引入了 FSM(有限状态机)。之前有人提问 (见 Ash issue #14) 使用 Ash 框架去编码如何去实现游戏的各种状态。我在学习 Ash 的过程也有类似的困惑，可能是习惯了 OOP(面向对象编程)，所以用实体系统框架开发的时候会有点不顺手。但其实这类框架本身是很灵活的。
问题的关键是：如何去控制这些组件。
2012-12-26 updated
什么是游戏开发中的实体框架 ?
原文：What is an entity framework for game development?
作者：Richard Lord
翻译：dreamana.com
上星期我发布了 Ash，一个用于 ActionScript 游戏开发的实体框架 (Entity Framework)，接着很多人问我“什么是实体框架？”。说来话长。
实体系统 (Entity Systems) 变得越来越流行，众所周知的比如 Unity，还有鲜有所闻的框架比如 Ember2, Xember 和我的 Ash 框架。有一个很好的理由：它们简化了游戏架构，促进在代码中职责分离得清楚，可以用得很乐。
在这篇文章里我将会引导你怎样从传统游戏循环 (Game Loop) 中发展到基于实体的架构。可能要花点时间。这里例子用 ActionScript 实现，因为我正在用这个语言，但是这架构可以应用在所有的编程语言上。
无论再怎么强大的 UI 组件库，个人觉得都不能适应各种项目的需求。而过分依赖 UI 组建构建应用，会导致交互设计单调。Flash 有个好处就是没有自带 UI 组件，不需要停留在 WIMP 的世界，但是为了迎合各种用户习惯，往往这却成了麻烦。
构建 MonoUI 的目的，不是为了提供几个见惯不怪的又不成型的 UI 组件。而是希望借此抛砖引玉，将 Flash 开发中不被重视又缺乏交流的一个方面提出来与大家共同探讨。
——《Stage3D Game Programming Beginner’s Guide》阅读笔记
Molehill 是什么 ?
Molehill 是 Flash Stage3D 技术的开发代号（现在正式命名 Stage3D）。它能让下一代 Flash 游戏通过显卡 GPU 硬件加速去渲染 3D 图形（或成千上万个“精灵”），从而降低 CPU 负载。
Molehill 不是什么 ?
Molehill 是非常低层的 API，只提供基本的 3D 渲染功能。它不是一个游戏引擎（如 Unity3d 或者 Unreal 又或者 ID Tech），一个游戏引擎还包含物理模拟，音频，音乐，碰撞检测等等补充的游戏函数。取而代之的是，你可使用 Molehill 这样的低层 API 去制作你自己的游戏引擎。与 OpenGL 或 Direct3D 相似，Molehill 是一些非常基本的函数集合，是游戏和游戏引擎的基本构件。
从 Flash 端将文件数据上传到服务端有各种各样的方法。