【杂言】 虽然实作上是以top-down的方式，从反组译开始找出指标、压缩规则， 但我还是以bottom-up的方式来解说中文化技术， 因为这样比较不会一次遇到大量名词与观念。 所以让我们假设已经知道文本、字库指标，先来看看常见的压缩规则与观念。 【正文】 由於早期卡匣昂贵，如何在有限的ROM里尽量压缩资料塞进去， 就成了早期游戏的基本要求。 会压缩的资料主要包括图像、字库、文本， 不过反正都是看成以byte为单位的连续资料，所以压缩时没太大差别。 事实上，因为连压缩规则都是每个游戏自由订定旳， 所以没有通则存在。不过我一般会分成下列几种类型： ================================================================== ‧无压缩型 - 无压缩的资料大致只包含资料本身与控制码。 控制码是各游戏各自订定的，可能包含结束码、换行码、 甚至主人公名字、取得道具名等非固定资料，也会以特定代码表示。 - 名词文本因为太短无压缩必要，因此通常没被压缩。 无压缩图像、字库通常不会有控制码，无压缩剧情文本则一定会有。 例如： 皇家骑士团一代中，武器名称是以未压缩形式存放在ROM里。 ソ ニ ッ ク ブ レ ー ド BF C6 AF B8 19 32 DA B0 19 2E 00 从上例可见有些字的代码长度是1 byte、有些是2 bytes。 最後的00就是用於判断名称末尾的控制码。 我们要如何知道每个字的代码是什麽？ 最简单的方法就是去找改名字的金手指， 这特别适用在文字量大、能取名的RPG与SLG游戏。 ‧字典型 - 用固定2~3个byte当作某些常用词(例如道具名、人名)的代码。 加上特定控制码就会直接透过代码取得名称。 - 这其实应该不算压缩，比较像引用.... 因为比起等下要讲的简单多了，所以省略(逃 - 多半使用在剧情文本上，大多利用名词文本当字典， 有时也会跟下面方法混用。 ‧参照型 - 将至今解压出的本文内容当参考对象， 指定"位移量"与"参照byte数"来得到重复出现过的句子段落。 - 图像、字库、剧情文本都可能使用。 - 以下举例介绍： ======================================================== SFC中最常见的压缩法是.... 用1个压缩byte来指示後面几个bytes内容， 用 bit = 1 或 0 来代表哪些是未压缩资料、哪些是参照资料。 FF 74 00 9A 00 CE 00 0E 01 FF 46 01 80 01 B1 01 D2 01 FF 10 02 51 02 88 02 9F 02 FF BB 02 E0 02 0D 03 3B 03 FF 60 03 9A 03 AC 03 D7 03 FF F9 03 25 04 5A 04 94 04 FF C9 04 08 05 38 05 78 05 FF 98 05 C0 05 FD 05 2E 06 FF 71 06 B2 06 EA 06 15 07 FF 3A 07 6A 07 A0 07 DD 07 FF 19 08 4E 08 85 08 AC 08 FF E2 08 23 09 56 09 92 09 FF CF 09 0A 0A 33 0A 66 0A FF 8D 0A BB 0A F0 0A 11 0B FF 36 0B 6C 0B B3 AB B0 DA FF DD 0D 3E FC 19 00 19 9C FF ED A4 F6 93 9A 9F A1 0D FF 20 91 E5 E0 86 95 1A AA FF E1 9C E3 95 F8 EF 9C E0 F7 A1 00 3E 07 EE EA 19 C2 9C FF 97 19 28 C3 19 21 C8 B1 FF 19 96 19 89 E4 0D 20 18 FF 1E FC E8 19 10 E5 F8 EF FB 9E FD 07 CA 19 A7 19 00 9F FF 93 E2 19 03 E3 92 EF 9D...(略) 以上面皇骑1代的压缩剧情代码为例： 当压缩byte为FF时，就表示後面8个bytes都是未压缩资料。 因为FF以2进位看时是 11111111， 而每个1都代表1byte的未压缩资料。 当压缩byte为F7时，因为F7以2进位看时是 11110111， 其中0是位在从右边(低位)数来第4笔的位置， 表示第4笔是参照资料(2 bytes)，其他7笔是1 byte未压缩: A1 00 3E 07 EE EA 19 C2 9C 这2 bytes参照资料转成2进位就是 00000111 11101110。 前5 bits用来表示需复制多少byte资料。 因为参照资料本身就占2 bytes了，最少要复制3 bytes才够本。 因此就算前5 bits换算十进位值为0，也会复制3 bytes过来。 如果前5 bits换算十进位值为X，就会复制 X+3 bytes过来。 後11个bits表示要复制的资料离多远。 因为111 11101110相当於十进位的-18， 因此会从已解压的资料尾部，向前推18 bytes作为开始复制的地方。 可以参考下面的解压资料，其中91 E5 E0就是被复制过来的资料。 0D、00都是控制码，用於表示换行、结束。 有兴趣的人可以推敲 FB 9E FD 07 CA 19 A7 19 00 9F ， 应该会得到符合下面解压的结果。 74 00 9A 00 CE 00 0E 01 46 01 80 01 B1 01 D2 01 10 02 51 02 88 02 9F 02 BB 02 E0 02 0D 03 3B 03 60 03 9A 03 AC 03 D7 03 F9 03 25 04 5A 04 94 04 C9 04 08 05 38 05 78 05 98 05 C0 05 FD 05 2E 06 71 06 B2 06 EA 06 15 07 3A 07 6A 07 A0 07 DD 07 19 08 4E 08 85 08 AC 08 E2 08 23 09 56 09 92 09 CF 09 0A 0A 33 0A 66 0A 8D 0A BB 0A F0 0A 11 0B 36 0B 6C 0B B3 AB B0 DA DD 0D 3E FC 19 00 19 9C ウ ォ ー レ ン 「 わ が 城 ED A4 F6 93 9A 9F A1 0D 20 91 E5 E0 86 95 へ 、 よ う こ そ 。 □ あ な た を お 1A AA E1 9C E3 95 F8 EF 9C E0 A1 00 3E 91 E5 E0 待 ち し て お り ま し た 。 「 あ な た EA 19 C2 9C 97 19 28 C3 19 21 C8 B1 19 96 19 89 は 悪 し き ゼ テ ギ ネ ア 帝 国 E4 0D 20 18 1E FC E8 19 10 E5 F8 EF 9E FD A1 0D と □ 戦 わ ね ば な り ま せ ん 。 20 19 A7 19 00 9F 93 E2 19 03 E3 92 EF 9D □ 星 が そ う つ げ て い ま す 这边要注意的一点是，参照资料的定义可能因游戏而不同。 有的用较多bits在容许复制的byte数； 有的用较多bits在容许的位移量， 我印象中皇骑2就用了3种以上定义来压资料。 也许有人会想问，上面紫色的是什麽。 注意看应该会发现，如果以每2个bytes为一组， 并且前後对调的话(SFC是low byte在前)，会有递增的趋势： (00 74) (00 9A) (00 CE) (01 0E) (01 46) (01 80) (01 B1) ....(略) 简单来说，每一组都是"位移指标"， 记录了从某处位移的距离。 此处的第1组(00 74)表示了第1段对话的位置， 是从解压後资料开始处算起的第 0x74 byte (十进位的116 byte)， 第2段对话是在第 0x9A byte位置，....以此类推。 这样游戏在显示对话时，才能很快透过位移指标找到特定对话。 中文化中有很多使用指标的机会，我们以後还会再陆续讨论。 当我们要中文化游戏剧情时，每段对话长度一定会有所变动， 所以要连位移指标都一起修改至新的正确位置才行。 之後，用最简单的压缩byte(FF)把改好的指标、剧情塞回去就行。 (事实上、一般应该是不会连指标都压缩，皇骑1应该是少数例子) ‧特殊型 - 有的游戏会自己定义一些奇怪的压缩规则，例如圣火降魔录。 因为特性不一，在此就不提出讨论，有兴趣可以自行寻找。 - 另一个不讨论的原因是，其实就算是特定压缩方法， 理论上也能透过反组译来知道压缩流程。 ================================================================== 这周大概就先介绍到此，我再想想下周要写什麽比较顺... -- --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 111.249.54.35