在TextureCache 加载贴图时:
这里s_etc1_alpha_endix可以提出一个全局接口cocos2d::setETC1AlphaEndix
可以把我分享的 https://github.com/halx99/cocos2d-x-pc-port down下来， 所以设计etc1 alpha 支持修改的地方，我都加了注释:
这里s_etc1_alpha_endix可以提出一个全局接口cocos2d::setETC1AlphaEndix
可以把我分享的 https://github.com/halx99/cocos2d-x-pc-port down下来， 所以设计etc1 alpha 支持修改的地方，我都加了注释:
目前的问题在于引擎对多纹理的支持不友好，需要自己写shader来达到目的。你的方法相当于在目前的实现上的一个“hack”，引擎里到处需要对ETC进行特殊处理，使得逻辑变得很复杂，所以我觉得维持现状，自己写shader解决吧。
嗯，不过如果引擎能实现，那么开发者应该会更加便利
嗯，如果要实现多纹理工作量不少，而且可能带来兼容性问题。目前兼容性问题被开发者认为是很严重的问题，很多时候也是没办法。
嗯，明白你的顾虑，不过Andorid平台采用ETC1纹理，带来的优势还是很可观的，由于是硬件解码，加载速度其实会快很多，另外最后APK包体是总资源的1/5, 甚至更小. 我们总资源370M， 最后apk 70M
4赞
@minggo 至于多纹理支持工作量大，这个我已经在3.10上实现， 我可以在3.11正式版发布后，提个pull request贡献我的代码, 到时候，多多审核斟酌. 兼容性问题倒是没什么，如果不用ETC1也不影响原有渲染
2赞
好啊，欢迎。
其实我们对硬件纹理支持的那块地方，是应该做成插件形式方便大家扩展。很早以前不是还有网龙自己的一套pnx格式么，类似的这种纹理优化、硬件纹理格式很多公司都有自己一套。
这个赞
自己搞一套pnx，还是软件层面的吧？目前我所知道Android 和 ios平台分别是etc和pvr, directx的dds
各家公司都有各自的解决方案，所以还是在引擎层面做到可扩展会更通用一些。
1赞
各家公司都有各自的解决方案，这里公司指的什么公司，硬件公司还是游戏软件开发公司，
如果说的是硬件生产商，各家硬件厂商对的硬件纹理格式都不一样? 硬件驱动上实现不遵循OpenGL或者DX标准？难道不是主流ios,android阵营？这个实在不理解呢，据我了解，硬件市场不是这样的， 求详解
各家CP，都有自己的纹理压缩解决方案。他们甚至自己会生出一些很奇怪的图片纹理压缩格式。一方面的确是压缩，另一方面也是资源加密，两者可得兼。