红警DIY论坛

 找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 101|回复: 0

【杂项】Ra2/YR平台及其扩展平台SHP文件压缩比较和绘制效率

[复制链接]
发表于 2019-7-27 01:04:14 | 显示全部楼层 |阅读模式
注:在此把SHP帧的方框称为FrameBound,将恰好包含所有非0号色的方框称为OffsetBound。

压缩格式
SHP的压缩方式分为两种,并且每帧可以拥有不同类型的压缩格式(当选择自动选择压缩时可能会存在这两种并存于一个SHP文件的不同帧中),暂且按照SB称之为Compression1和Compression3。他们的区别主要是在于OffsetBound中对其中0号色的处理有所不同,以及每一行像素的头部有所不同,其他的均是一样的:
我们先假设现在有一行像素(SHP存储的序列号为):
00 00 00 00 FF 00 FF 00  00 00FF 00 00 00 00 00
上面是假设OffsetBound的宽度为16,一行有16个像素,注意FrameBound-OffsetBound中的区域是不论哪种压缩都不会存储的。
那么它在Compression1中,被转变成:
00 00 00 00 FF 00 FF 00  00 00FF 00 00 00 00 00
Compression1将OffsetBound中的每个像素连续地原封不动地存在文件中,下一行的像素数据紧接着存在这一行的后面。
而在Compression3中,它被转变成:
0D 00 00 04 FF 00 01 FF 00 03 FF 00 05
0D 00 = 0D = 13,表示这一行的数据有13个字节,这个数字之后的数据表示这一行的真正像素数据,00 04(00 N)表示这里有4(N)个连续的0号色,后面的00 01,00 03,00 05同理,其中其他序号(FF)则继续原封不动地存储。我们将其手动解压(去掉开头的行长度),得到:
00 00 00 00 FF 00 FF 00 00 00 FF 00 00 00 00 00,于是得到了和原始数据完全相同的结果,是无损的(RLE)压缩。
由此我们可以得出一个结论:Compression3时每256个或以内连续的0号颜色不论多少个都由2个字节存储,那么我们很容易发现一个问题,从上面的例子也可以看出,哪怕是只有一个0号色,也得用2个字节来存储。因此在仿色等情况存在时,如果素材总体形状接近一个方块,Compression3可能反而会使得文件大小增大。
我们使用一个50x50的单帧shp为例子,这个SHP由0号色像素和非0号色像素相间而成。采用Compression1(常说的非压缩)得到文件大小2532字节。而采用Compression3(常说的压缩),其文件大小变成了3882字节。获得了反向压缩的效果。
绘制效率
对于这两种SHP的绘制的区别也主要存在于对0号颜色的处理上:Compression1的绘制通过判断OffsetBound内每个像素是否是0来判断是否需要画这个像素,而Compression3则是先判断是否是0,再读取连续的0的个数并跳过这些像素从而可能减少判断次数。
因此,因此我们容易发现当间隔为单个0号色的时候,处理0时Compression1要优于Compression3。容易想到,在使用仿色透明的时候,容易出现间隔1个0的情况。
综合之前的压缩方法,在使用仿色,并且素材形状比较接近OffsetBound的时候(比较“饱满”),Compression3可能既不能取得良好的压缩效果,也不能取得良好的绘制效率,Compression1反之。而当素材中含有大量连续的0号空白时,Compression1和3的角色可能就从上述中反了过来。
以上仅基本分析,复杂的情况有待实践。
SHP文件体积以及限制
在大量使用SHP素材后应该注意一个问题:即使你的电脑装有128GB内存,Ra2/YR也只是32位应用程序。它能够给素材们申请的内存要少于2GB,并且当游戏需要某个SHP时,会直接将整个素材文件载入,而完全没有分批处理。在无法继续加载shp时,会出现众多动画无法绘制的情况并且有崩溃的可能。

注:以上的比较主要基于理论基础,并没有经过巨大多复杂情况的测试,可能会有大量与上述较为不符的情况。
若有雷同请联系删除本帖子。
若有错误欢迎各位大佬指出!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x
您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|Archiver|手机版|管理员邮箱|红警DIY官方论坛

GMT+8, 2019-8-19 09:53 , Processed in 0.019850 second(s), 16 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表