我尝试使用 zlib 打包和压缩游戏客户端资源数据。如果我压缩数据，它会随着文件大小的减小而减少磁盘 I/O，但在解压缩时会增加 CPU 使用率。
问题1
如果用于渲染的资源被压缩，处理（渲染和解压缩）会使用 CPU，所以我认为它似乎很慢，对吗？
如果没有压缩，则磁盘 I/O 没有改变，并且不会出现额外的 CPU 使用率。如果您只读取文件的一部分，可以使用 CreateFileMapping()、MapViewOfFile() 函数减少磁盘 I/O。
问题2
在资源的情况下，例如未压缩的图像（例如tga，而不是png），当我们必须读取整个文件（例如图像文件）时，我们无法利用CreateFileMapping（），MapViewOfFile（），所以我认为压缩资源更好，你怎么看？
问题3
打包时对资源数据进行压缩是怎么想的？
我使用 zLib 1.2.7，取自此处。我已在 Microsoft Visual Studio 2010 中将其编译为静态库并将其添加到我的项目中。
我需要解压缩一些用 deflate 算法压缩的二进制数据。这里是：
unsigned char rawData[114] =
{
0x00, 0x00, 0x00, 0x00, 0x15, 0x82, 0x05, 0x9D, 0x62, 0x91, 0x9A, 0x86, 0x26, 0xF3, 0x45, 0xBF,
0xE1, 0x69, 0x19, 0xA8, 0x80, 0x21, 0x08, 0x43, 0xF1, 0xEF, 0xCC, 0x01, 0x68, 0x4E, 0x3C, 0x06,
0x59, 0x6D, 0x90, 0xB2, 0x1F, 0xC3, 0x87, 0xC2, 0xBF, 0xC0, 0x90, 0xBE, 0x1F, 0x11, 0xB6, 0xD7,
0xB7, 0x06, 0x18, 0x32, 0x5F, 0x80, 0x8F, 0x09, 0xF1, 0x81, 0xF2, 0xB8, 0xC8, 0x9E, …所以我试图创建一个 python 脚本来为 MMF2+Lua 制作的游戏生成一个关卡，但我遇到了一些我不知道如何修复的问题。
生成一个带有游戏边框的 16x16 空关卡会给出以下结果（缩小）：
78 5E 63 20 0A FC 27 00 40 86 8C AA C1 1D 02 23 3D 7C 08 27 32 00 9F 62 FE 10
它应该是一个扁平的 18x18 数组，其边缘具有0x00，其余部分具有0xFF。
我的 python 脚本使用完全相同的输入生成此数据zlib.deflate：
78 9C 63 60 20 06 FC 27 00 46 D5 8C AA C1 A7 86 30 00 00 9F 62 FE 10
它们是不同的，但膨胀它们会给出相同的数据。但是，当我将数据放入游戏时，尝试加载关卡时它崩溃了。
这两个值之间到底有什么不同，我可以修复它吗？
我试图在iPhone应用程序中使用zlib将文本文件压缩为gzip文件作为测试.我使用以下代码
const char *s = [[Path stringByReplacingOccurrencesOfString:[NSString stringWithFormat:@".%@", [Path pathExtension]] withString:@".gz"] UTF8String];
gzFile *fi = (gzFile *)gzopen(s, "wb");
const char *c = readFile(Path.UTF8String);
gzwrite(fi, c, strlen(c));
gzclose(fi);
其中readFile()返回const char*一个从使用该文件而获得fgets()的功能.问题是,当我使用它来压缩文件时,它不会压缩它,而是gzip文件比原始文件大.例如,我有一个90字节的文本文件,使用此方法后,gzip的大小为98字节.为什么gzip不比原始文件小？
我花了几天时间阅读 zlib（以及 gzip 和 deflate）RFC，我可以说它们有点垃圾。缺少一些细节，所以我打开这个问题。
我正在尝试解析 zlib 数据，我需要了解有关标头的一些详细信息。
首先，RFC 说会有 2 个字节，CMF并且FLG.
CMF分为 2 个 4 位部分。第一个是CM，第二个是CINFO。
的可能值是CM什么？RFC 说这8意味着deflate并且那15是保留的，但是其余的可能值呢？
CINFO 另一方面，如果我正确理解 RFC，应该总是 8（如果我错了，请纠正我）。
跳过FLG和可能的FDICT，我们进入该Compressed data部分。RFC的这一部分说：
For compression method 8, the compressed data is stored in the
deflate compressed data format as described in the document
"DEFLATE Compressed Data Format Specification" by L. Peter
Deutsch. (See reference [3] …