纹理图片数据量巨大，一个256x256 RGBA16的原始象素就有128KB之多，而一个实际应用中会用到巨量的纹理图片。这些数据都需要从硬盘或存储卡上读进内存，然后再上传到显存里。通过 有损压缩，图片的文件尺寸可以急剧减小，512x512的真彩BMP有768KB，转成100%质量的JPG就只有235KB。
不过象JPG这种常见图象压缩格式对于多数应用的内存占用和显示总线带宽占用并没有直接的好处，因为还得解压缩成原始象素再传给显卡，而且还有加载时的解 码计算负担。这是因为显卡的纹理解码硬件不理解JPG格式。所以，在没有显卡硬件支持的情况下，用压缩格式保存纹理没什么意义，特别是对于手持移动设备来 说，解码象JPG这种复杂格式是很浪费电的。
考虑到现代游戏对纹理图片的严重依赖，及相应的对视频总线的巨大压力，硬件实时解压缩获得了广泛的支持，不过这个还没有一种格式获得多个厂家的支持。在 OpenGL ES里已经为此定义了一个标准接口glCompressedTexImage2D(..., format, ..., data)，不过纹理数据的格式则没有标准，要参考厂商的SDK或文档获得format值。这也就意味着，使用了压缩纹理之后就不能跨平台了。对于 OpenGL ES应用来说可能问题不大，可以用不压缩纹理做为起点，然后针对不同硬件平台转换相应的优化版本。而对于标准OpenGL应用来说问题可能也不太大，因为 真正值得关注的也就ATI vs. NVIDIA吧。
纹理压缩算法除了要求高压缩比、低失真之外，可随机读取任意一点及便于低成本硬件实现是最大的挑战。2700G支持的PowerVR Texture Compression，就是一种按照这种需求开发的高效率压缩算法。对于PVRTC算法及Texture Compression算法的演化，可以参考Simon Fenney题为"Texture Compression using Low-Frequency Signal Modulation"的论文，可以在PowerVR的GLES PCE SDK里找到。
PVRTC有两种压缩算法，512x512 RGB的原始象素768KB，PVRTC 4BPP压缩后为128KB，PVRTC 2BPP压缩后为64K。不过PVRTC 2BPP效果看上去明显比较差。
值得一提的是，Intel 2700G SDK里带有一个 PVRTextureTool.exe 可将BMP压缩成PVRTC格式，这个tool版本比较低是1.x的。在PowerVR SDK里有更新版本(3.0)，新版本明显好用得多，可以处理alpha channel，支持OpenGL纹理格式等等。这个tool有命令行版本，也有GUI版本，而且还有一个库封装了算法和文件格式处理代码可用来制作自己 的工具。PVRTC的纹理存储顺序是从上到下逐行保存的，而OpenGL ES定义纹理数据是从下到上逐行排列的，所以使用3.0版本并且在编码时勾上OpenGL选项是非常必要的。
根据实测，PVR PCE不支持带MipMap的PVRTC数据。可能设计者认为对于现有的240x320或480x640的屏幕来说，MipMap实在是意 义不大吧。终于知道为什么PCE上跑得好好的程序在X51v上却显示不出纹理来了，原来WinCE是没有当前目录这个说法的，fopen ("t.pvr")会去"My Devices"目录里找这个文件，显然是找不到，把相应的.pvr文件放进去就好了。
2700G或PVR PCE SDK里都带用glext.h，里面定义了所需要的常量，主要有用的是GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG 等传给glCompressedTexImage2D()的format常量。PVRTextureTool生成的文件是.pvr格式的，其格式在SDK 文档里有详细的描述，甚至连struct都定义好了。
总的说来利用上压缩纹理还是相当简单而直接的，所以闲话少说，看代码吧：
主程序部份，提示一下，可以用't'轮换纹理图片，用'm'轮换贴图公式，其它也就是画了个带纹理的矩形而矣。主要的代码在 PVRTexture.upload()里
不过象JPG这种常见图象压缩格式对于多数应用的内存占用和显示总线带宽占用并没有直接的好处，因为还得解压缩成原始象素再传给显卡，而且还有加载时的解 码计算负担。这是因为显卡的纹理解码硬件不理解JPG格式。所以，在没有显卡硬件支持的情况下，用压缩格式保存纹理没什么意义，特别是对于手持移动设备来 说，解码象JPG这种复杂格式是很浪费电的。
考虑到现代游戏对纹理图片的严重依赖，及相应的对视频总线的巨大压力，硬件实时解压缩获得了广泛的支持，不过这个还没有一种格式获得多个厂家的支持。在 OpenGL ES里已经为此定义了一个标准接口glCompressedTexImage2D(..., format, ..., data)，不过纹理数据的格式则没有标准，要参考厂商的SDK或文档获得format值。这也就意味着，使用了压缩纹理之后就不能跨平台了。对于 OpenGL ES应用来说可能问题不大，可以用不压缩纹理做为起点，然后针对不同硬件平台转换相应的优化版本。而对于标准OpenGL应用来说问题可能也不太大，因为 真正值得关注的也就ATI vs. NVIDIA吧。
纹理压缩算法除了要求高压缩比、低失真之外，可随机读取任意一点及便于低成本硬件实现是最大的挑战。2700G支持的PowerVR Texture Compression，就是一种按照这种需求开发的高效率压缩算法。对于PVRTC算法及Texture Compression算法的演化，可以参考Simon Fenney题为"Texture Compression using Low-Frequency Signal Modulation"的论文，可以在PowerVR的GLES PCE SDK里找到。
PVRTC有两种压缩算法，512x512 RGB的原始象素768KB，PVRTC 4BPP压缩后为128KB，PVRTC 2BPP压缩后为64K。不过PVRTC 2BPP效果看上去明显比较差。
值得一提的是，Intel 2700G SDK里带有一个 PVRTextureTool.exe 可将BMP压缩成PVRTC格式，这个tool版本比较低是1.x的。在PowerVR SDK里有更新版本(3.0)，新版本明显好用得多，可以处理alpha channel，支持OpenGL纹理格式等等。这个tool有命令行版本，也有GUI版本，而且还有一个库封装了算法和文件格式处理代码可用来制作自己 的工具。PVRTC的纹理存储顺序是从上到下逐行保存的，而OpenGL ES定义纹理数据是从下到上逐行排列的，所以使用3.0版本并且在编码时勾上OpenGL选项是非常必要的。
根据实测，PVR PCE不支持带MipMap的PVRTC数据。可能设计者认为对于现有的240x320或480x640的屏幕来说，MipMap实在是意 义不大吧。终于知道为什么PCE上跑得好好的程序在X51v上却显示不出纹理来了，原来WinCE是没有当前目录这个说法的，fopen ("t.pvr")会去"My Devices"目录里找这个文件，显然是找不到，把相应的.pvr文件放进去就好了。
2700G或PVR PCE SDK里都带用glext.h，里面定义了所需要的常量，主要有用的是GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG 等传给glCompressedTexImage2D()的format常量。PVRTextureTool生成的文件是.pvr格式的，其格式在SDK 文档里有详细的描述，甚至连struct都定义好了。
总的说来利用上压缩纹理还是相当简单而直接的，所以闲话少说，看代码吧：
主程序部份，提示一下，可以用't'轮换纹理图片，用'm'轮换贴图公式，其它也就是画了个带纹理的矩形而矣。主要的代码在 PVRTexture.upload()里