java生成tga图片_游戏制作行业为什么使用TGA格式的贴图而不使用PNG格式？

大家的回答槽点太多了，我是来辟谣的：

TLDR：只使用 TGA 不用其它格式的，只有一个原因，懒。

具体解释下大家找的各种理由：

理由1：PNG 的 alpha channel 会被优化掉，所以用不了？

这个根本不是什么问题，大量的游戏用 PNG 存储纹理，有的游戏不用 PNG 存储通用纹理，也会用 PNG 存储 UI，因为 DXT/PVR 之类的纹理硬压缩格式都是有损的，再棱角分明的 UI 元素上，效果很差，所以即便游戏大量使用 DXT/PVR，任然会再 UI 部分使用 PNG 格式保存纹理。

而 256 色 PNG + Alpha channel 这种格式占用的空间是非常低的，对于一些图形简单的游戏，用的比较多。

理由2：PNG 需要解码，TGA 不需要解码，所以速度快？

错了，你们自己实际去测试一下，1000张 PNG/JPG 和 1000 张同样的 BMP/TGA 图片的载入速度，前者比后者快几倍，为啥？你 TGA/BMP 是节省了解码速度了，但是加载时候的 I/O 操作却因为尺寸更大浪费了更多时间，现代 CPU 解码 PNG/JPG 基本都是小儿科，JPG 比 PNG 复杂，但是都有 JPG 硬件加速解码。所以你 TGA 比 PNG 快是不成立的，特别是图像大一点，或者首次加载(没有缓存时)，你解码节省的时间 1 ，而 I/O 多浪费的时间是 10。

当然也有解码相当费时的格式 FLIF，它解码浪费了 100，而 I/O 节省了 10，这也是阻碍 FLIF 发展的一个重要原因。

理由3：游戏资源都要打包，打包文件都有压缩，即便用 TGA，也会被压缩的很小。

这条看着好像有道理，但是他们没搞懂，PNG 除了压缩外，还有有多个方向的预测，然后换成差分编码后再使用标准压缩技术压缩，有点类似一个弱智点的视频编码器的帧内压缩方法，虽然比较弱智，但是很多时候使用 PNG 压缩会比 TGA + zip/rar/lzma2 压缩要强。

随便测试了一张普通 UI 图片(某 Windows 窗口截图)：PNG：74.8KB (TinyPNG 优化)

TGA：1.04MB

TGA+RAR：198KB

TGA+lzma2：170KB

TGA 搭配 LZMA2 进行压缩了，也还有 170KB，占用是裸存 PNG 的 2.3 倍。

理由4：因为要使用硬件压缩格式 dxt/pvr 所以不用 PNG？

这条还是说得过去的，毕竟 dxt/pvr 使用更少的显存，除了 UI 外，大部分游戏纹理基本都可以使用硬压缩格式。这些硬压缩格式还能保存 mipmap，又更方便了一些。

但是这其实还是有很多改进的空间，dxt/pvr 在磁盘上的占用虽然比 BMP/TGA 小不少，但是比起 PNG/JPG 还是大很多，所以更好的做法其实是在磁盘上存储 JPG/PNG，然后载入的时候实时动态转存 dxt/pvr，mipmap 的话，可以分开存储+动态生成，比如你需要 8 张 mipmap，美术画好最近的 0 号和 4 号，其他全部 bicubic 插值重生成就得了。

加载阶段动态压缩 dxt/pvr 的工具有很多，比如 pc 上的 dxt1-5 的 libsquish，unity 里面也有好几个插件专门动态生成 etc/pvr 格式的纹理。

默认的 dxt/pvr/etc 压缩工具非常慢，因为他们都是高精度计算，而 libsquish 之类的实时压缩，在不视觉上基本看不出区别的情况下，采用低精度的近似运算。

因此最好的做法其实是使用传统图片格式保存纹理，这样游戏安装包/更新包就能小很多，用户下载都会快很多，载入时动态转成 dxt/pvr/etc 格式，还可以弄个缓存，下载时下载的传统压缩格式，然后下载完了一次性转换成本地的 dxt/pvr/etc 格式，这样后面运行也不会需要额外运行一遍 libsquish 之类的库来压缩一次。

最终解决方案是啥？简单的话，界面使用 PNG(尽量用 8位带 alpha)，非界面使用 dxt/pvr/etc。

复杂点的话，界面纹理使用 webp 或者更好的 bpg，普通纹理使用 dxt/pvr/etc。

极限的话，全部使用 bpg(有损+无损)，需要 dxt/pvr/etc 的地方动态生成(可以加缓存)

至于 FLIF，压缩率确实非常不错，比无损 BPG，无损 webp/png 高很多，可惜解码速度实在慢的无法接受了，有待观察吧。

--