cocos2d 资源图片优化

来源:互联网 发布:sql server2005个人版 编辑:程序博客网 时间:2024/05/26 19:16
原文链接:http://www.cocoachina.com/bbs/read.php?tid-214811-page-1.html
pvrtc 和 etc是硬件支持的格式,因此,不会进行内存和显存解码,将会省许多
同时,由于不会解码,那CPU到GPU的传输量就会变少,在手机平台这种总线带宽小的设备上,可以得到一定量的性能提升。

但pvrtc只适合IOS,etc适合android, 需要做两个平台的分别优化,并且etc1(刚刚有修改,先前是说的etc,随着OPENGL ES 3.0的发布,etc2也出了,支持ALPHA通道,但就目前的市场,可以不用考虑)不支持ALPHA通道,所以需要解决一些问题。

png24/32是无压缩格式的RGBA通道,质量是最好的
JPG是有损压缩的格式,不支持ALPHA通道,但是是安装包最小的。

但JPG会进行内存解压,也就是说,一个JPG读入到内存后,与png24/32读入内存是一样的。

综上可知。
prvtc,etc不仅可以减少安装包大小,也能减少内存显存开销,并能提升一定的性能
png24/32可以保证原始质量,但内存和安装包大小 会很大
jpg不能省内存显存,但jpg可以使安装包较小,且它不支持ALPHA通道。

而对于pvrtc,etc打出来的文件大小,比jpg要大得多。

在此,我们还可能会用到一种叫 grunt - png8的压缩格式,这种格式可以将png24/32压缩到1/4的大小,且几乎可以维持图像质量需求,这个比JPG大,但支持ALPHA通道。


那选择策略就需要针对不同的资源进行优化了

1、如果游戏是那种大量关卡资源,但同关卡中出现的资源和元素较少,这种一般不会有内存和性能瓶颈,那可以选择JPG+grunt-PNG8,这样一来,可以将安装包大小减少到1/4左右
2、如果游戏是那种同屏复杂度较大的,那就需要对游戏中的元素分类处理了, 一般对于UI,直接使用png8即可, 对于单张场景,我们使用JPG,对于里面的小元素,比如特效,人物精灵动画等,则建议使用pvrtc或者etc格式。

纹理格式的选择不是死的,只要你明白了不同格式的优缺点,那就可以很容易地做出判断。。




在这里,顺便说一下,如何处理独立的ALPHA通道。
首先,美术出图还是用原始PNG。 我们可以用PYTHON的IMAGE库,将RGB和ALPHA分离出来。RGB可以用原图,而分离出来的ALPHA通道,使用8位的PNG来存放,注意,这里和上面说的PNG8是有区别的。东西不一样。
这样我们就有两张纹理图,color + alpha_mask 现在我们开始进行纹理转换,我们肯定是要将color图转换为pvrtc或者etc1的,而对于alpha_mask,就看你爱好 了,可以转,可以不转。

这里还有另一种处理方法,就是将ALPHA纹理拼接到原来的纹理上,这样我们的纹理就只有一张,涉及的资源加载的改动就较少。 这个大家自行考虑



有了这个,我们要处理的,就是SHADER和纹理的ALPHA MASK问题,首先我们在纹理加载处,要进行纹理判定。
对于分享的ALPHA MASK,我们有两种方法处理, 一种是统一命名, 比如 ooxx.png 打包为etc后,变成  ooxx.png(etc1格式,只是后缀保持原来的) + ooxx.png.alpha_mask(这个格式根据自己爱好,可以直接是8位PNG图) 这样一来,我们在加载ooxx.png的时候,无脑判定一下ooxx.png.alpha_mask是否存在,如果存在,就加载这个纹理,并存放于CCTexture2D里面,同时提供一个getAlphaMask来访问。


SHADER肯定是要改的,不管用哪种方法,SHADER都得改,对于上面这种,正常情况下的SHADER是
vec4 c = tex2d(tex,uv)
那我们要改成


vec4 c = tex2d(tex,uv)
c.w = tex2d(alpha_tex,uv).w
就可以了。


而在SPRITE等提交纹理的地方,我们通过判定getAlphaMask来确定是否要切换SHADER,并且设置这个alphaMask参数。




说到这里,可能许多朋友会问,我在代码里使用 display.newSprite("ooxx.png") 但是我的ooxx.png打包后,是ooxx.pkm怎么办。
这就是为什么我上面要把ooxx.pkm的名字换回ooxx.png的原因,这样一来,逻辑代码就不用动了。


而随之而来的,就是2.2.x版本中,加载纹理的时候, 是使用后缀名判定。
这个太好办了,把3.x版本中,通过文件头判定纹理格式的代码弄进来,即可实现后缀 名无关的纹理格式判定。


PPS:有了后缀名无关的纹理格式判定,我们会想,每次都检查 纹理.alpha_mask是否存在,会不会影响效率, 答案是肯定的,要多一次磁盘路径查找。 如果你觉得这点效率是心结,那你完全可以将ooxx.png和ooxx.png.alpha_mask使用工具(如PYTHON)写成一个文件,依然叫ooxx.png,但我们强加一个头,比如 'T','E''X','P' 如果发现头四字节(由于大小端问题,记得逐BYTE读取)是TEXP,我们认为这是我们的原图+ALPHA_MASK的纹理包,然后根据自己的格式读取出数据即可,后面的步骤,就和上面的一样了。


上面只是一些经验上的描述,实际实现过程中其实还是会遇上许多特别的问题。 大家共勉。
谢谢~
0 0
原创粉丝点击