[研究]从ROM填充率看卡带成本的降低

TriForce

利用业余时间做的小程序终于完成了，手头游戏不多，测试了一下，公布一些大作游戏ROM容量的使用情况：

填充率计算方法：查找ROM文件中连续的、数值完全相同的数字（基本全是0或FF），这些数字被认为是废数据。这里使用的参数是以BYTE为单位，连续量下限设为16。

游戏名称                        填充率（%）

FC ROM：
火焰外传                        99
ROCKMAN                        94
马里奥3                        91
赤色要塞                        94

GB ROM：
GB WARS                        87
银河战士2                        88
SAGA2                        95
魂斗罗1                        97
风来西林GB                        99
ROCKMAN5                        89
SAGA3                        99
圣剑传说                        98
第二次G                        88
梦见岛                        91

SFC ROM：
DQ3                        94
DQ6                        98
DQ5                        99
多拉基亚776                95
圣战系谱                        97
银河战士3                        88
SAGA3                        93
SAGA2                        93
圣剑传说3                        97
TACTICS OGRE                98
幻想传说                        96

N64 ROM：
风来2                        89
时之笛                        96
马里傲赛车64                96
生化2                        100
超级马力奥64                97

GBC ROM：
大金刚 2000                50
大金刚 2001                48
星海传说                        87
风来西林GB2                58
WARIO LAND3                59
DQ3                        86
DQM2                        51
心跳文艺篇                        92
梦见岛DX                        84

注：GBA ROM前一阵换硬盘时全丢了。

focus

色块里的byte也是连续的哦

john

随便补几个吧，GBA

超级马里奥Ａ　　　　　97%
恶魔城～晓月的圆舞曲　76%
最终幻想战略版Ａ　　　61%
口袋妖怪红宝石　　　　100%
超级机器人大战Ｄ　　　99%
幻想传说　　　　　　　100%

john

最初由 TriForce 发布
[B]GBC ROM：
大金刚 2000                50
大金刚 2001                48
[/B]

这几个似乎不妥
厂家为什么不换用更小容量的ROM存放数据？
看来算法的确有问题

TriForce

最初由 focus 发布
[B]色块里的byte也是连续的哦 [/B]

16字节里只要1个不连续就不算，16个以上连续的话，配色不是一般的垃圾（GBC记得每字节4像素、SFC和GBA一般两像素）……
这种情况很少见到的。

Ares

想知道FF6是多少

TriForce

最初由 john 发布
[B]这几个似乎不妥
厂家为什么不换用更小容量的ROM存放数据？
看来算法的确有问题 [/B]

不知道，开始不太相信。手动查了大金刚2001开头的几百K，发现里面有64KB长度以上的全空白。

发现的最大的一个：422c0h ―― 60010h，全0；长度接近128KB。

补几个：

MD：
超级忍2   92%
皇帝的财宝  97%

TriForce

从结尾处查了点，比较长的还有：
3e1d40h ―― 3f8000h（>80K）
3cdfd0h ―― 3d4000h（>24K）
3b1b00h ―― 3c0000h（>50K）

发现超大空白段：
327dd0h ――380000h （最开始的一部分偶尔有一两行非全0的出现）
长度超过350KB，一个火焰外传的容量出来了。

john

最初由 TriForce 发布
[B]不知道，开始不太相信。手动查了大金刚2001开头的几百K，发现里面有64KB长度以上的全空白。

发现的最大的一个：422c0h ―― 60010h，全0；长度接近128KB。

补几个：

我们的太阳 83%
ADV WAR 2  91%
黄金太阳2    92%

MD：
超级忍2   92%
皇帝的财宝  97% [/B]

ADV WAR 2，我用最普通的ROM缩减工具都能缩到76%
你这个算法…………

ROTO

光写百分比没意义，要把这个rom的容量在旁边写出来，并把浪费的容量写出来这才直观

TriForce

最初由 john 发布
[B]ADV WAR 2，我用最普通的ROM缩减工具都能缩到76%
你这个算法………… [/B]

普通ROM缩减工具？用没用压缩算法？

这个东西我用ZIP、RAR试过。也能压缩近一半的大小；但能压缩掉的并不都是废数据。24bit的BMP文件里可以说没有废数据，但用ZIP一压缩很多都有超过50%的压缩比，转换成PNG格式后大小往往也能降下一个数量级。这些可都是100%无损的转换和压缩。

能把游戏做好已经够不容易了，多填点容量也很花精力，最后还要为各种压缩算法做优化不成？^_^

如果游戏图象的配色越简单，ROM里图象数据（一般分量很大）段大体上就越有规律可寻（贴近压缩算法要求），压缩时的压缩比就越大。但是这些数据虽然简单，终归不是废数据。SFC后期很多大作ROM压缩比都很低，远没有象GBA游戏那样动不动就能有超过50%的压缩比，这里，美工的优秀应该是原因之一。

TriForce

最初由 Ares 发布
[B]想知道FF6是多少 [/B]

没有ROM。
用ZIP等东西压一下吧，一般来说，压缩比越小，填充率就越高。
如果里面动不动就一大堆连续的0或-1，压缩比会很高的。

john

最初由 TriForce 发布
[B]普通ROM缩减工具？用没用压缩算法？

这个东西我用ZIP、RAR试过。也能压缩近一半的大小；但能压缩掉的并不都是废数据。24bit的BMP文件里可以说没有废数据，但用ZIP一压缩很多都有超过50%的压缩比，转换成PNG格式后大小往往也能降下一个数量级。这些可都是100%无损的转换和压缩。
[/B]

当然不是压缩
用UE32，可以看到从这里开始往后就全是FF……注意看旁边的滚动条，比例是多少




或者，用这个也是相当简单的……

TriForce

临界值16字节可能有人觉得少了，提升临界值，用0.5K（512字节）、4K（4096）、64K（65536）做临界值对几个GBC ROM再测一回。


64K应该算不能再高了，如果ROM里某段数据连续超过64K都完全一样，没人会觉得它是正常数据了吧（GBC一个MEMORY BLOCK都没64K长）。

游戏名---ROM大小（BYTE）---填充率1（临界16字节）----填充率2（512）----填充率3（4K）----填充率4（64K）
大金刚2000------4096K---------50%（浪费2053K）----------57%（浪费1746K）---65%（浪费1428K）---80%（浪费837K）
大金刚2001------4096K---------48（2131K）----------55（1829K）------------63（1520K）----------75（1032K）

星海------------------4096K----------87（539K）-----------89（458K）------------91（380K）----------95（192K）


西林GB2------------4096K----------58（1736K）--------62（1551K）---------70（1242K）--------82（750K）
西林GB1------------512K------------99（7K）-----------（后面的测试就免了吧……）


WARIO LAND3----2048K--------59（835K）-----------62（786K）--------66（691K）-----------86（279K）
WARIO LAND2----2048K--------45（1119K）---------46（1098K）------52（987K）-----------73（546K）

DQM2------------------4096K---------51（2025K）---------52（1984K）------54（1879K）---------59（1667K）

也有几个高填充的：
MARIO TENNIS----2048K-------82（377K）-----------90（195K）--------94（121K）----------100（0）

心跳文艺篇----------4096K-------92（316K）-----------94（253K）-------97（139K）----------100（0）

DQ3（GBC）--------4096K-------86（562K）----------88（479K）--------95（222K）-----------100（0）
DQ3（SFC）--------4097K--------94（233K）----------96（147K）--------97（125K）------------98（65K）

SFC  DQ3中有一个长度超过64K的段3efe50h - 4001f0h (all \'ff\')

可见临界值设成16还是4096，差别不大，16是比较合适的一个值。

TriForce

最初由 john 发布
[B]当然不是压缩
用UE32，可以看到从这里开始往后就全是FF……注意看旁边的滚动条，比例是多少

[/B]

看来这个ROM有问题，地址同样是61d6e0h，后面的FF全不见了，成了无用的乱码。相信你的才是真正从卡带里DUMP出的。

john

我那个ROM也有问题
换了一个GBA noIntro校验过的，容量更小了

firesun

rom的无用数据填充大都应该是放在rom的尾部吧
比如一个游戏实际数据是8300MB，刚刚好超过了8192这样一个64Mb的界限，只好直接放到128Mb的卡带里面，剩余容量都是DummyData。
放在文件结尾之前的连续相同数据应该只是巧合而已……
以上是对于GBA游戏来说的。
GB、GBC、SWAN都有bank的概念，数据存放的时候有可能为了不让一个数据存放在两个bank之间而放入一些DummyData的。

john

最初由 firesun 发布
[B]rom的无用数据填充大都应该是放在rom的尾部吧
比如一个游戏实际数据是8300MB，刚刚好超过了8192这样一个64Mb的界限，只好直接放到128Mb的卡带里面，剩余容量都是DummyData。
放在文件结尾之前的连续相同数据应该只是巧合而已……
以上是对于GBA游戏来说的。
GB、GBC、SWAN都有bank的概念，数据存放的时候有可能为了不让一个数据存放在两个bank之间而放入一些DummyData的。 [/B]

不一顶吧
老妈1+2，末尾有一段FF，但是中间也有大量的00/FF填充

Pluto_Shi

那是分开1和2用的

TriForce

最初由 firesun 发布
[B]rom的无用数据填充大都应该是放在rom的尾部吧
比如一个游戏实际数据是8300MB，刚刚好超过了8192这样一个64Mb的界限，只好直接放到128Mb的卡带里面，剩余容量都是DummyData。
放在文件结尾之前的连续相同数据应该只是巧合而已……
以上是对于GBA游戏来说的。
GB、GBC、SWAN都有bank的概念，数据存放的时候有可能为了不让一个数据存放在两个bank之间而放入一些DummyData的。 [/B]

8300超过8192，以前SFC时的做法是加块小点的ROM，比如超过了8300-8192=108Kb加一块1Mb的ROM，SFC的ROM就有12Mb、24Mb、48Mb这种大小，MD也有40Mb的ROM，现在ROM多半是不值钱了，超过了8Mb的话，哪怕只有一点，直接就用16Mb来装了。
以前的SFC、FC、GB游戏，ROM填充达到95%以上，我觉得正常的做法是难以达到这种填充率的，恐怕做游戏甚至企划的同时就已经考虑到ROM容量了，不影响游戏各方面平衡性的前提下，为了尽量填满，会考虑多设计一些东西，有时是砍掉一些东西。

我认为放在结尾前的连续0和-1绝对不会是巧合――太常见了，而且有的数据段超长（针对GBA游戏）。但是GBA游戏是连续地址空间，我猜想造成这种现象的原因可能是这样：

现在的程序设计都讲究面向对象的思想，不同种类敌人的数据是统一设计的，比如规定AR中所有敌人角色的动作图象最多的可以有6桢，于是给所有敌方角色都留下存储6桢的空间，很多达不到6桢图象的敌方角色对应的数据段末尾就会留下大量的空白。同样，规定最大的敌人尺寸为64*64，那么所有敌人图象都使用64*64空间来存储；类似的还有敌人的种类数目、关卡等，最大的一个场景地图有512*1024（也许是由游戏引擎决定的），那么所有的都留这么大空间，等等，以次类推。

游戏企划的时候就这样计算容量，这样，游戏具体设计的时候就留有很大余地，也大大简化了地址的计算。避免了很多设计中的麻烦。缺点就是浪费了大量的ROM卡带容量，当然，前提是ROM卡带的容量已经不值钱了。

或者把原因归咎到开发工具的不完善上，也许SFC时期ROM容量珍贵，开发工具提供自动优化和分配地址的功能，即使没有提供，厂商也会开发类似工具。而现在不需要了。

以前SFC游戏里中间数据段即使出现空白也很短，也许是BANK的问题实在没办法。到了GBA，BANK限制没了，反而因为ROM的贬值和为了省心而出现了长得多的大段空白。

GBC游戏很多填充率50%以下，太出乎意料了。大概游戏容量本来就小，即使浪费率超过一半，也没多少成本吧（中间出现连续数百KBYTE的空白，这绝对不是BANK的问题了）。

至于GBA，除了ROM卡带的贬值，厂商做游戏时的漫不经心大概也是一大原因。

TriForce

最初由 john 发布
[B]我那个ROM也有问题
换了一个GBA noIntro校验过的，容量更小了

[/B]

难怪。
现在烧录卡有节省容量功能的，选ROM都要费心了――有人（有意或无意）把ROM里的空白数据伪装起来，使垃圾无法识别。也许第一时间得到的ROM是有收藏价值的……

新下的MARIO ADV1，现在检查竟然达到了94%，记得绝不会有这么高的（记忆中不超过75%）……

上面测出的填充率看来只多不少，应以最少的为准。

TriForce

最初由 john 发布
[B]不一顶吧
老妈1+2，末尾有一段FF，但是中间也有大量的00/FF填充 [/B]

用UltraEdit看了一下，
现在下的GBA ROM（来自某网站），中间很少再有大段0和-1出现了，和硬盘坏掉以前机器上的ROM完全不同。以前的ROM很多都看过，中间大段的0和-1是家常便饭。
前面测的GBA ROM填充数据全部作废，马上删除。

john

最初由 Pluto_Shi 发布
[B]那是分开1和2用的 [/B]

不是吧
006a4300h开始有一小段00
中间隔了一段，006d1670h后面又是00
0090c8d0h，00
00b2bb10h开始是FF

这也太多了吧

john

最初由 TriForce 发布
[B]用UltraEdit看了一下，
现在下的GBA ROM（来自某网站），中间很少再有大段0和-1出现了，和硬盘坏掉以前机器上的ROM完全不同。以前的ROM很多都看过，中间大段的0和-1是家常便饭。 [/B]

我的ROM都是经过GBA NoIntro DAT校验过的
绝对正确

TriForce

最初由 Pluto_Shi 发布
[B]那是分开1和2用的 [/B]

分开1和2可以留下明显空白的话――分开音乐、图象、代码，分开不同角色数据、不同场景，分开所有的“不同”都有理由留下空白。^_^

TriForce

最初由 john 发布
[B]我的ROM都是经过GBA NoIntro DAT校验过的
绝对正确 [/B]

那前面说的这几个如何？

超级马里奥Ａ　　　　　97%
恶魔城～晓月的圆舞曲　76%
最终幻想战略版Ａ　　　61%
口袋妖怪红宝石　　　　100%
超级机器人大战Ｄ　　　99%
幻想传说　　　　　　　100%

超级马里奥Ａ、口袋妖怪红宝石、超级机器人大战Ｄ、幻想传说。
这么高的填充率，特别是那两个100%，即使SFC游戏都没能达到，难以想象。

TriForce

最初由 Pluto_Shi 发布
[B]那是分开1和2用的 [/B]

想起来了。
就是因为以前下载后常用UltraEdit查看ROM，发现远远并非只有末尾有空白，才专门编写这个程序的。中间出现空白，可以说几乎每个ROM都有，而且长度不可忽视。

john

最初由 TriForce 发布
[B]那前面说的这几个如何？

超级马里奥Ａ　　　　　97%
恶魔城～晓月的圆舞曲　76%
最终幻想战略版Ａ　　　61%
口袋妖怪红宝石　　　　100%
超级机器人大战Ｄ　　　99%
幻想传说　　　　　　　100%

超级马里奥Ａ、口袋妖怪红宝石、超级机器人大战Ｄ、幻想传说。
这么高的填充率，特别是那两个100%，难以想象。 [/B]

我没你那样精确的计算工具，我只看ROM尾
用UE32看了一下，口袋红末尾有一点点FF，大概0.1%左右，中间有几小段00的空白
TOP看了一下，末尾是用00混合FF填充的，实际上大概是99.5%，中间空白极少
机战D几乎是无懈可击的

Pluto_Shi

最初由 TriForce 发布
[B]分开1和2可以留下明显空白的话――分开音乐、图象、代码，分开不同角色数据、不同场景，分开所有的“不同”都有理由留下空白。^_^ [/B]

机战og就是，机体和人物中间就是一堆00
不过mother特殊，因为是未加多大改动的移植版，很多数据排列几乎和fc/sfc相同，没有多少分隔段

TriForce

最初由 firesun 发布
[B]仔细想了一下，想起来一些事情应该是引起数据当中dummydata产生的原因。
比如一个GBA的char文件，里面的14×3的区域是画了数据的，而每“14”个char后面都有2个char的空余，这样在编译data时候这个char文件就只能按照16*3来剪切文件，这样以来就有2×3的区域是dummydata了。
GBA开发时候不是非常节省的时候经常会出现这种情况，美工画出来的char没有重新整理就交出来了，因此dummydata的确很多的。目前SWAN游戏的开发依然要求尽量在美工阶段就整理char文件（至少我所知的都是的……）。

楼主有空弄几个swan游戏试试看？？ [/B]

正好这里有前几天下的一个“约束之地”。
结果如下：
ROM大小：8192KB

以BYTE为单位：
临界值16：空白1034K，填充率87%
临界值256：空白707K，填充率91%
临界值4096：空白575K，填充率93%
临界值32K：空白69K
临界值64K：空白0
所以ROM里应该有两个超过32KB的空白段。

WORD单位（16位）：
临界值16：空白900K，填充率89%
临界值256：空白671K，填充率92%
临界值4096：空白527K，填充率94%

相比GBA游戏，这样的填充率应该算很高了。
不过即使这样，数百K的空间也够装好几个FC经典了。

SWAN游戏看来都不小，网速又不快。
这个程序32KB，有ROM的话程序给你如何？

john

老Tri给我吧
随便用什么空间传一下就成

TriForce

最初由 john 发布
[B]老Tri给我吧
随便用什么空间传一下就成 [/B]

我这里没法开FTP，你指定一个地方吧，邮箱也行。

john

john_nt@163.com
谢

TriForce

发过。

john

收到
昨天搞太晚了，今天早点睡觉。明天放出测试结果

firesun

Swan的rom在公司，家里没有……


GBA上，（char、16色模式下）每个char文件8×8个dot，每个dot为4bit，这样每个char就是8×8×4＝0x100bit＝0x20Byte
如果是两个连续的char就是0x40Byte
GBA画图工具上是32×32个char排列的
如果多放1条的话就会有32×0x20Byte……
如果每个char文件都是32×32没有剪切过的就是32×32×0x20Byte＝32KByte

代码部分有大段DUMMYDATA的不大可能，代码当中就算有一切有规则数据直接存放在rom里面也不会很大，大都作数据列表使用的

john

WS游戏，临界值16KB/64KB

SD Gundam - Operation U.C.     74/81
超级机器人大战Compact 2 Volume 3     95/100
机动战士Gundam SEED   86/90
SD Gundam G-Generation Mono-Eye Gundam     97/100
半熟英雄    73/76
Macross - True Love Song   97/100
钟楼  50/50
Final Fantasy   90/100
Final Fantasy 2       99/100
Final Fantasy 4      70/83
口袋战士     100/100

john

再来几个SFC

Crono Trigger       100/100
FF6   100/100
FF4 100/100
FF5 100/100
大航海时代2  100/100
第4次超级机器人大战  100/100


这也太寒了点吧[M]023[/M]

TriForce

最初由 john 发布
[B]再来几个SFC

Crono Trigger       100/100
FF6   100/100
FF4 100/100
FF5 100/100
大航海时代2  100/100
第4次超级机器人大战  100/100


这也太寒了点吧[M]023[/M] [/B]

SFC游戏，临界值还设16K和64K，太不象话了。
很多只设16字节，填充率都95%以上了……
想想，SFC游戏卡带那么贵，容量最多才4MB（两个除外），FF6甚至还是10亿日圆成本的制作，里面能有16K以上的大段空白？：败家子行为啊。