我所遭遇过的游戏中间件---Redux,关于Redux:
推荐课程:C#教程。
Substance Redux 是一款纹理处理软件加中间件,专门用于纹理生成和压缩。具其用户指南介绍,它能够对纹理集进行优化,可以将现有压缩算法的性能提高50%或更多。其压缩方式可是无损压缩,也可以是无损压缩。压缩时可以由用户自定义压缩比和图像质量。
Redux可以针对批量纹理文件进行压缩打包。操作流程是新建一个Project项目,为该项目导入若干个纹理文件,可以设置每一个纹理的压缩参数。最后导出压缩文件。Redux可以对多种格式的图像文件进行压缩。如果输入图像的长宽不为2的N次幂,Redux会自动将其拉伸至2的N次幂。ReduxSDK提供的Demo中将压缩文件解压成符合DDS格式的功能。
Redux最大的卖点在于其图像生成功能,它可以用若干个简单的图元,经过算法生成复杂的图像.图元只需要占用很小的磁盘空间,生成方法的保存也用不了多少磁盘空间,按他们官方的说法,游戏中占用磁盘最大的部分是纹理,而使用了Redux可以将纹理占用的磁盘空间降低到最小,从而最多能将游戏的发布包大小降低到二分之一.
二.Redux 压缩方式
Redux 提供3种纹理压缩方式:
Redux Mode 1(Redux 模式 1)是无损压缩算法,在大多数情况下压缩比最小。但是,通常它的渲染速度最快。
Redux mode 2(Redux 模式 2)是提供高质量图像的快速压缩算法,但是尺寸缩减率为 40% 左右。
Redux mode 3(Redux 模式 3)实现了图像质量和尺寸缩减率的大致均衡。图像质量低于模式 2,但是通过此模式可以获得更高的压缩比。尺寸缩减率为60% 左右。
在实际操作中,我将300张DDS文件进行压缩,发现Redux mode 2与Redux mode 3生成的文件大小是一样的。我当时没有在意这些DDS文件具体是什么压缩格式,估计大部分为DXT5的.
三.Redux 压缩文件
Redux 主要针对批量纹理文件进行压缩,压缩后的文件分为两类。一个“头”文件,包含主要数据文件的目录并向解压缩代码提供每个纹理的位置。该文件的扩展名为 .RDXH,用于存储每个纹理的详细信息,例如纹理名称、文件夹和路径。一个或多个“数据”文件,包含实际已压缩的纹理,这类文件的扩展名为.RDXC。第二类文件将采用“块”。可以将所有纹理存储在一个大文件中,这样就只需要处理一个数据“块”。对于导出的压缩“块”文件,可以有以下三种设置方式:
1. No Chunks(无块)——即一个大数据文件,包含项目中每个单独的纹理;
2. Chunks split according to a size limit(根据大小限制来分割块)——例如,每 4 MB 数据创建一个新块;
3. Chunks split according to content(根据内容分割块)——即为每个纹理创建一个新块。此时会生成一个头文件,若干个chunk文件。
生成压缩文件之后,如果对原纹理文件有任何改动,则必需重新生成压缩文件。这种压缩方式不太符合我的想法。我所希望的是通过一个纹理名找到一个压缩文件,加载该文件,解压缩并生成纹理。如果使用Redux,引擎需要先加载一个.RDXH头文件,生成一个Redux定义的ReduxHandle对象。然后根据纹理名找到纹理下标索引,再通过索引值使用Redux提供的接口获取纹理数据。创建只含有一个纹理文件的Redux工程,这样生成的压缩文件中有含有一个纹理。这是很麻烦的事情,工作量会很大。
四.Redux 解压缩
ReduxSDK提供的Demo中将压缩文件解压成符合DDS格式的数据,我曾经对其性能做过测试:首先使用300个DDS文件进行测试。原文件大小为59.6M,如果使用RAR压缩后大小为25.9M。DDS的压缩格式,当时没有记录,估计大部分为DXT5.
压缩方式 |
文件大小 |
加载文件时间 |
同步创建纹理时间1 |
同步创建纹理时间2 |
不压缩 |
59.6M |
2355ms |
6172 ms |
6133 ms |
Redux Mode1 无损压缩 |
19.5M |
743ms |
25016 ms |
24985 ms |
Redux Mode2 40% reduction |
17.3M |
702ms |
25862 ms |
25860 ms |
Redux Mode3 50% reduction |
17.3M |
674ms |
25878 ms |
25911ms |
Redux Mode1 无损压缩 Texture per chunk |
20.6M |
813ms (此为创ReduxHandle的时间) |
29027ms |
29089ms |
用引擎加载本地文件创建这300个纹理需要的时间约为8秒,通过解压Redux文件来创建300个纹理需要花费30多秒时间,是本地加载的4倍。
针对不同大小的文件,创建纹理所使用的时间如下表所示:
纹理大小 |
文件大小 |
引擎加载创建时间 |
Redux Mode1创建时间 |
Redux Mode2创建时间 |
Redux Mode3创建时间 |
128*128 |
11K |
1ms |
105 ms |
31 ms |
30 ms |
256*256 |
65K |
11 ms |
228 ms |
82 ms |
82 ms |
512*512 |
257K |
49 ms |
206 ms |
140 ms |
137 ms |
1024*1024 |
1025K |
176 ms |
297 ms |
418 ms |
415 ms |
2048*2048 |
5462K |
242 ms |
2263 ms |
2265 ms |
2294 ms |
五.图像生成功能
使用若干个简单的图元,经过算法生成复杂的图像.这里最大的问题是,美术无法适应这种做图方式.正常情况下,美术用绘图板在PS中做图,而Redux则要求美术以解析的方式,先想象出一张图由多少图元组成,再设计好图元的组合方式.如何让图元生成图像,这种逻辑思维太颠覆了.一般人很难高效的用它提供的软件做图.就是因为这个原因,最终这个中间件没有使用.
六.软件问题
(1)项目的属性设置时,设置Mode2与Mode3生成的压缩文件是一样的。
(2)对单幅纹理的压缩设置中Redux Mode3 与项目属性中的Mode3不一样。
设置Redux Mode2与Redux Mode3没有任何区别.
(3)对于一些纹理文件压缩后数据大小,要大于未处理的数据大小。
原DDS文件大小为6.475KB,压缩后为6.682KB
原DDS文件大小为57.6KB,压缩后为140.9KB
(4)使用有损压缩,对一些纹理会产生明显的斑驳.
(5)当时我使用的版本,如果纹理的数目过多,会导致软件崩溃。
(6)Redux线程不安全,所以不能同时解压多个纹理。
七.Redux 后记
我个人对Redux的感觉是:这个中间件很奇怪.目前的发展,硬盘大小不是问题,内存的消耗也不是问题.最大的问题是提高效率.为了提高效率我们经常使用一些用空间换时间的算法.而Redux则反其道而行之,它所做的无非是用时间换空间.以上这些材料还是我两三年前整理的,文章中的性能测试数据仅供参考,不知道现在Redux发展的如何,也不太清楚市面上有多少游戏使用它.用Google搜索了下,也没多少关于它的网页.也许Redux会在移动游戏上有所发展,毕竟现在移动端的磁盘空间比PC端小了很多.
Atas ialah kandungan terperinci 游戏里redux什么意思. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!