[研究]从ROM填充率看卡带成本的降低
- focus色块里的byte也是连续的哦
- john这几个似乎不妥
厂家为什么不换用更小容量的ROM存放数据？
看来算法的确有问题 - TriForce16字节里只要1个不连续就不算，16个以上连续的话，配色不是一般的垃圾（GBC记得每字节4像素、SFC和GBA一般两像素）……
这种情况很少见到的。 - Ares想知道FF6是多少
- TriForce从结尾处查了点，比较长的还有：
3e1d40h ―― 3f8000h（>80K）
3cdfd0h ―― 3d4000h（>24K）
3b1b00h ―― 3c0000h（>50K）
发现超大空白段：
327dd0h ――380000h （最开始的一部分偶尔有一两行非全0的出现）
长度超过350KB，一个火焰外传的容量出来了。 - johnADV WAR 2，我用最普通的ROM缩减工具都能缩到76%
你这个算法………… - ROTO光写百分比没意义，要把这个rom的容量在旁边写出来，并把浪费的容量写出来这才直观
- TriForce普通ROM缩减工具？用没用压缩算法？
这个东西我用ZIP、RAR试过。也能压缩近一半的大小；但能压缩掉的并不都是废数据。24bit的BMP文件里可以说没有废数据，但用ZIP一压缩很多都有超过50%的压缩比，转换成PNG格式后大小往往也能降下一个数量级。这些可都是100%无损的转换和压缩。
能把游戏做好已经够不容易了，多填点容量也很花精力，最后还要为各种压缩算法做优化不成？^_^
如果游戏图象的配色越简单，ROM里图象数据（一般分量很大）段大体上就越有规律可寻（贴近压缩算法要求），压缩时的压缩比就越大。但是这些数据虽然简单，终归不是废数据。SFC后期很多大作ROM压缩比都很低，远没有象GBA游戏那样动不动就能有超过50%的压缩比，这里，美工的优秀应该是原因之一。 - TriForce没有ROM。
用ZIP等东西压一下吧，一般来说，压缩比越小，填充率就越高。
如果里面动不动就一大堆连续的0或-1，压缩比会很高的。 - john当然不是压缩
用UE32，可以看到从这里开始往后就全是FF……注意看旁边的滚动条，比例是多少
或者，用这个也是相当简单的…… - TriForce
看来这个ROM有问题，地址同样是61d6e0h，后面的FF全不见了，成了无用的乱码。相信你的才是真正从卡带里DUMP出的。 - john我那个ROM也有问题
换了一个GBA noIntro校验过的，容量更小了 - john不一顶吧
老妈1+2，末尾有一段FF，但是中间也有大量的00/FF填充 - Pluto_Shi那是分开1和2用的
- TriForce难怪。
现在烧录卡有节省容量功能的，选ROM都要费心了――有人（有意或无意）把ROM里的空白数据伪装起来，使垃圾无法识别。也许第一时间得到的ROM是有收藏价值的……
新下的MARIO ADV1，现在检查竟然达到了94%，记得绝不会有这么高的（记忆中不超过75%）……
上面测出的填充率看来只多不少，应以最少的为准。 - TriForce用UltraEdit看了一下，
现在下的GBA ROM（来自某网站），中间很少再有大段0和-1出现了，和硬盘坏掉以前机器上的ROM完全不同。以前的ROM很多都看过，中间大段的0和-1是家常便饭。
前面测的GBA ROM填充数据全部作废，马上删除。 - john不是吧
006a4300h开始有一小段00
中间隔了一段，006d1670h后面又是00
0090c8d0h，00
00b2bb10h开始是FF
这也太多了吧 - john我的ROM都是经过GBA NoIntro DAT校验过的
绝对正确 - TriForce分开1和2可以留下明显空白的话――分开音乐、图象、代码，分开不同角色数据、不同场景，分开所有的“不同”都有理由留下空白。^_^
- TriForce想起来了。
就是因为以前下载后常用UltraEdit查看ROM，发现远远并非只有末尾有空白，才专门编写这个程序的。中间出现空白，可以说几乎每个ROM都有，而且长度不可忽视。 - john我没你那样精确的计算工具，我只看ROM尾
用UE32看了一下，口袋红末尾有一点点FF，大概0.1%左右，中间有几小段00的空白
TOP看了一下，末尾是用00混合FF填充的，实际上大概是99.5%，中间空白极少
机战D几乎是无懈可击的 - Pluto_Shi机战og就是，机体和人物中间就是一堆00
不过mother特殊，因为是未加多大改动的移植版，很多数据排列几乎和fc/sfc相同，没有多少分隔段 - firesun仔细想了一下，想起来一些事情应该是引起数据当中dummydata产生的原因。
比如一个GBA的char文件，里面的14×3的区域是画了数据的，而每“14”个char后面都有2个char的空余，这样在编译data时候这个char文件就只能按照16*3来剪切文件，这样以来就有2×3的区域是dummydata了。
GBA开发时候不是非常节省的时候经常会出现这种情况，美工画出来的char没有重新整理就交出来了，因此dummydata的确很多的。目前SWAN游戏的开发依然要求尽量在美工阶段就整理char文件（至少我所知的都是的……）。
楼主有空弄几个swan游戏试试看？？ - john老Tri给我吧
随便用什么空间传一下就成 - TriForce我这里没法开FTP，你指定一个地方吧，邮箱也行。
- john
- TriForce发过。
- john收到
昨天搞太晚了，今天早点睡觉。明天放出测试结果 - firesunSwan的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里面也不会很大，大都作数据列表使用的