避免资源的双重压缩


13

我将.pngs用于纹理,并在.zip游戏项目的文件中使用虚拟文件系统。这意味着我的纹理被压缩和解压缩了两次。这个双重压缩问题的解决方案是什么?我听说过的一种解决方案是将.tgas用于纹理,但是似乎很久以前,因为我已经听说过。另一个解决方案是在上实施解压缩GPU,由于这样做很快,因此无需考虑开销。


2
相关:如果您使用的是jpeg,则许多具有自己格式的zip程序甚至可以将它们压缩20%,因此不一定那么糟糕。您最担心的双重压缩点是什么?需要太长时间吗?许多格式甚至可以原样存储已经压缩的数据,根本不对它们进行任何解压缩。
PlasmaHH 2014年

Answers:


17

zip格式支持几种不同的压缩算法。您可以对存档中的每个文件使用不同的算法。当您要存储已经无法从zip归档中进行额外压缩(例如PNG)的压缩文件时,可以使用完全不压缩的“存储”算法对这些文件进行编码。7-zip的“添加到存档”对话框使您可以在“压缩强度”下进行选择。

但是,当您的存档中不仅有图像而且还有其他更可压缩的资源时,为每个文件选择算法可能很繁琐。在这种情况下,您可能宁愿选择压缩存档中未压缩的图像格式。

TGA格式知道很多不同的模式,其中有些压缩,有些则没有。当您不想使用压缩时,请确保在使用的图形编辑器的导出选项中选择正确的压缩。另一种非压缩图像格式是BMP(Windows位图)。

这是我做的测试。我将相同的图像(当前项目中的一项资产)以不同的格式多次添加到zip归档文件中,其中一些具有正常强度的“放气”算法,而另一种具有“存储”的算法。抱歉,德语GUI。第二列为未压缩大小,第三列为压缩算法,第四列为压缩大小。

在此处输入图片说明

如您所见,对PNG进行压缩编码仅节省了0.3%,而对deflate编码的BMP缩小为原始文件的十分之一,该原始文件甚至小于PNG版本。这让我很惊讶。我本来希望PNG较小,因为应该针对图像数据优化PNG的压缩方法,而对于ZIP则不是。一个可能的解释是,我的图像编辑器(GIMP)向PNG文件添加了很多元信息,而BMP却不这样做。

未压缩的TGA在压缩之前和之后的文件大小方面与BMP相似,而压缩的TGA文件的压缩通过ZIP进一步改善,尽管不如未压缩的版本大。

除了放气和其他压缩强度设置以外,可能还需要尝试其他算法。哪种组合可获得最佳效果,可能取决于纹理的样式。但是,您可能还会考虑对游戏的资产负载进行基准测试,并让解压缩性能影响您使用哪种设置的决定。

底线:如果要避免双重压缩同时文件大小仍然较小,请PNGStorezip算法或BMP压缩zip算法一起使用。


5
我在我的一些照片上做到了这一点,并且BNG图像的PNG(压缩级别9)始终击败zip(压缩级别超)大约20%。因此,它应该像元信息一样具有效果。
Trilarion 2014年

3
png的隔行扫描选项降低了可压缩性,但允许仅从图像文件的第一部分提取低分辨率图像(例如在通过低带宽连接下载时),那么墙是否活动了?除此之外,png已经使用deflate进行压缩。
棘轮怪胎

似乎您使用的PNG压缩器性能不佳,可以通过PNGOUT来运行文件,并且得到的结果不会被压缩的bmp文件打败。
aaaaaaaaaaaa 2014年

您的BMP或TGA是24位还是32位?特别是BMP,它们更可能是24位,并且未压缩的TGA大小表明它也是24位。您可能没有在这里比较“喜欢”。
Maximus Minimus 2014年

@JimmyShelter TGA和BMP均为32位,带有Alpha通道-我确定。
菲利普

7

不用担心

当.zip文件中使用的“放气”算法遇到一块已经很好压缩的数据块(如.png图像的像素数据)时,会发现它无法有效地对其进行压缩,并将其存储为文字未压缩的数据。在解压缩端进行复制所需的开销很小。

http://en.wikipedia.org/wiki/DEFLATE


3
有时候,简单的,感知到的问题并不一定是真正的问题。即使实际上存在两次解压缩的开销,解压缩deflate也是一个非常快的操作,我想开销只是可以测量的。
aaaaaaaaaaaa 2014年

请问压缩到底需要很长的时间来实现,该文件是不可压缩的?
user253751 2014年

相对地,是的。我不知道典型的.zip压缩程序用于选择块编码的启发式方法,但它可能像尝试所有编码并保持最佳结果一样简单。在开发过程中,如果必须将数据保存在.zip中,则可能要强制使用所有内容store而不是deflate节省时间,然后使用deflate所有要发布的版本。
罗素·博罗戈夫

2

看起来已经给出了一些非常好的答案,但我想我还要再给出一个:

What are the solutions to this double compression problem?

解决方案:什么都不做。

基本原理:没有任何问题-是的,您两次压缩了信息,但是为什么要为此担心呢?数据太大了吗?减压太慢了吗?这是否比您此时可能要添加,完善,测试和/或调试的数十种功能重要?


不必要地做两次事情本身就是一个问题。至少我已经这样认为。但是,当然,您的建议也是正确的。内存和解压缩速度都可能是个问题,尽管在这种情况下不是这样,因为我不是在写商业游戏。
user1095108 2014年

我是专业的游戏开发人员,我可以向您保证,除非存在实际的,已记录的性能问题,否则我们就不会再为此担心了-它需要花费0.99美元的购买费用或广告展示次数来支付比方说的8小时以正确地“纠正”此问题。两次做某事不是问题,尽管可能效率不高。尽管在这种情况下,您不会做两次相同的事情-您已将图像数据存储为PNG进行压缩,并且将一堆文件存储在一起。
NPSF3000

是的,但是一旦完成,它就可以用于多个项目。如果您考虑使用DEFLATE算法-八十年代以来一直保持不变。如果您进行了编程,那么您会很老套,但是,如果您知道算法,则可以说可以在GPU上实现该算法,并在多个项目中享受超快的解压缩速度。
user1095108 2014年

因此,您每月花2个星期的时间在GPU上实施Deflate?然后您意识到,您将要比Y部署在X平台上,并通过Z破坏算法。如果您想制作游戏,着眼于制作游戏,不必担心降低性能等不必要的事情。
NPSF3000,2014年

一旦知道算法(重新)实现,它应该很容易。快速,而不是2周或一个月。那就是我想说的。它从80年代就已经存在了,为此花一些时间可能是值得的。
user1095108 2014年

1

如果使用PNG和OGG等专用格式,则无需压缩ZIP。

通过再次将它们压缩为ZIP,PNG,OGG和其他已经压缩的格式不会变得更小。压缩的100MB PNG仍约为100MB。

脚本,配置文件和其他基于文本的格式从压缩中受益匪浅,但是,相比之下,它们通常很小,它们不会存储那么多数据。如果您的游戏为100MB,则文本文件可能占整个游戏的1MB,即使您可以通过压缩使它们成为100KB,也只能赢得900KB,不到1%,这几乎不值得付出。

您甚至可能想要直接使用文件系统,而不是使用基于虚拟zip的文件系统。这将使修补非常容易:您可以交换所有修改过的文件。


2
有时,关于是否使用.zip文件,别无选择。例如,在android平台上,.apk是一个.zip文件,其中可能包含资源。
user1095108 2014年

3
另外,使用archive绝对有优势,并且ZIP文件提供压缩和归档结构。
MrCranky 2014年

是的,我知道,我只是说使用本地文件系统也有优势。我有点“保持简单”的拥护者。
API-Beast
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.