Don't Alpha That Pixel! - 1504020523
视频发布时间
2014年6月25日
视频介绍
Rendering content with alpha blending is a common practice for apps and games across web and mobile. But this visual technique does not come for free! In this talk, we will cover the difference between alpha blending/ alpha testing , how each one effects your content pipeline, and peel back the layers to see the performance differences in these techniques on various types of mobile hardware. Alpha isn't free, and as a developer, maximizing every pixel for performance can make a day and night difference in the look and feel of your app. #perfmatters
视频推介语
暂无，待补充。
译者信息
翻译
润稿
终审
原始链接
中文字幕
翻译流水号
加入字幕组
解说词中文版：
如果你在手机上运行2D游戏
可能你会非常关心渲染的性能
但是最大的性能问题
可能来自于一个古怪的组合 α混合 两个带有透明图层的图像通道混合的透明度计算
过度绘制和如何创造你的纹理贴图集 多张位图拼成一张使得一次缓存读取搞定 可以节约内存
我们从第一个开始
现代2D游戏充斥着精彩的图像
来为场景制造视觉效果
但是当你开始分解它时
你意识到绘制你的环境这件事情
实际上是一场复杂的舞蹈
包含着多个图像层
例如 背景层 地面信息
（动画）精灵 最后 UI数据
时不时的我们会发现
一些对形成最终场景起不到作用的
奇怪的额外的层会出现
实际上这些额外的绘制
浪费了很多性能
而这些性能在移动平台上是弥足珍贵的资源
可以看到实际上有两种
如何渲染图像和场景的办法
一种是按照从后到前的顺序
先绘制远离摄像机的地方的几何图形
再绘制靠近摄像机的地方的几何图形
最后的结果是最后绘制的像素
最靠近摄像机
另一种是从前到后的次序
首先绘制靠近摄像机的图像
然后逐渐的向远方前进
尽管两种技术的渲染顺序
产生相同的像素颜色
从后到前导致了对最终结果毫无用处的
2倍工作量
我们常称之为 过度绘制
性能不同的原因源自于
现代图形API工作的方法
你看OpenGL ES（嵌入系统用）和所有它的桌面兄弟版本（OpenGL）
支持一种叫深度测试的模式
好处是让你避免处理一些像素
这些像素对产生最终图像无用
它是如何工作的
当屏幕上的某个像素被更新了颜色信息时
它距离摄像机的深度也被存储 （就是距离，深度是从垂直于屏幕的Z轴方向去体会的）
当光栅化（像素点绘制器）尝试在屏幕上的同一位置绘制另一个像素
我们首先测试新来的像素点
相对于老像素点的深度
如果新像素点离摄像机更远 那就被直接扔掉
这是节能循环因为不需要计算任何颜色
而如果新来的像素点更靠近摄像机
那就要继续了
计算新像素点的颜色信息 然后写回到颜色缓存中（存放像素点信息的一个或几个缓存）
过度绘制是一个描述
屏幕上的像素在单帧中
被重新绘制多少次的术语
例如 像这样绘制一个大的背景图片
然后在顶层（Z轴方向）绘制一个箱子 它的顶层绘制另一个
然后在顶层放一些字
当你打开分析器的过度绘制模式
你会看到屏幕的一些部分
被处理的次数最多
如果你的屏幕如下面这样红透了
那肯定是有性能问题了
有些像素对最终场景是没有用的 对这些像素做的任何工作
都是浪费时间
对于2D游戏来说α混合是一类
最大的过度绘制源头
一般来说大多数场景
必须在渲染时打开α混合选项
因为那些纹理使用一些
有透明通道的几何图形
当你打开α混合选项在游戏中渲染这些对象时
你被迫只能从后到前渲染你的场景
这是因为在每次绘制中 透明通道操作需要
颜色缓存中已经有像素存在用来混合
这增加了屏幕上已存像素点
被重绘的次数
事实是 你绘制游戏几何图形的顺序（Z轴上）
对你游戏的性能有着深远的影响
理想中 你想要做的是
按照从前向后的顺序绘制所有不透明的几何图形
这样会减少过度绘制发生的总量（因为被前方已绘制的几何图形遮挡的像素点，被计算Z轴深度后可以直接抛弃）
同时按照从后向前的顺序绘制所有含透明度的几何图形
那是为得到想要的样子（前一个像素点的透明部分要和后面那个像素点的透明部分运算）
必须做的（必须先有后面的，再绘制前面的）
但是啊 相信我 说易行难
我读了一篇来自Google Play的1000个游戏的分析
发现其中大多数
把含透明度和不透明图像包到一个纹理贴图集
这是典型的坏主意
用来做这个操作的纹理贴图集软件
并不总是输出每个图像信息的类型
让你能知道哪些原来是含透明度的
哪些原来是不透明的
结果是你不得不假设
场景上所有东西都是含透明度的
忽略这带来的性能问题
按照从前到后的顺序渲染所有东西
为了在你的游戏中改掉这个问题 方法其实很简单
当创建你的贴图集时 区分你的含透明度和不透明
对象到不同纹理
这会让你在运行时基于纹理类型
在渲染几何形状到最终场景之前
排列他们的顺序
新的流程将有助于减少过度绘制
并有助于你的场景渲染的更快
哦还有一件事
一旦你区分了不透明纹理
到他们的贴图集中 确保正确的使用
GP（图形处理器）纹理格式压缩它们
ETC PVR和DXT都被多层次的硬件支持
将会减轻分发量和减少你的纹理
在GPU（图形处理器单元）中占据的尺寸 这是大家都喜欢的 对吧
不管怎样事实是你
不应该对使用α混合掉以轻心
除了达成你想要的样子之外
还有些你可能没有意识到的性能问题的负担
所以三思以后 再想想透明度 然后一如既往 记住 性能问题
Last updated
Was this helpful?