GC、Wii汉化技术漫谈（上） by HyperIris
GC、Wii汉化技术漫谈（上）
HyperIris
fsstudio at 263.net
2009.05.28
最近换了个樱桃的茶轴键盘，有了点打字的欲望，本来就准备在TP项目之后金盆洗手，于是就整理一套GC、Wii汉化的资料吧。
预备知识：GC、Wii使用的是PowerPC 750家族处理器，内存数据使用Big-Endian，在PC上处理的时候要注意。
首先是GC ISO格式：GCM，先说这个，这是修改游戏内容的第一步。
GC游戏所用的格式被称为GCM，文件尺寸为1,459,978,240 字节，其实质内容并非传统意义的ISO，而是一个自定义结构的BIN文件，如下（信息来自于YAGCD，http://hitmen.c02.at/files/yagcd/yagcd/chap13.html#sec13）：
偏移 尺寸 内容
0×00000000 0×0440 Disk header (”boot.bin”)
0×00000440 0×2000 Disk header Information (”bi2.bin”)
0×00002440 (0×2000 ?) Apploader (”appldr.bin”)
FST (’fst.bin’)
其中我们关心的是两个内容，游戏的可执行程序和文件分配表，这两个数据保存在Disk header，下面是Disk header的详细内容，其中关键内容已经用红色标记出来：
开始 结束 尺寸 内容
0×0000 0×0003 0×0004 Game Code
1 Console ID
2 Gamecode
1 Country Code
0×0004 0×0005 0×0002 Maker Code
0×0006 0×0001 Disk ID
0×0007 0×0001 Version
0×0008 0×0001 Audio Streaming
0×0009 0×0001 Stream Buffer Size
0×000a 0×001b 0×0012 unused (zeros)
0×001c 0×001f 0×0004 DVD Magic Word (0xc2339f3d)
0×0020 0×03ff 0×03e0 Game Name
0×0400 0×0403 0×0004 offset of debug monitor (dh.bin) ?
0×0404 0×0407 0×0004 addr (?) to load debug monitor ?
0×0408 0×041f 0×0018 unused (zeros)
0×0420 0×0423 0×0004 DOL偏移
0×0424 0×0427 0×0004 FST偏移 (”fst.bin”)
0×0428 0×042B 0×0004 FST尺寸
0×042C 0×042F 0×0004 最大FST尺寸
0×0430 0×0433 0×0004 user position (?)
0×0434 0×0437 0×0004 user length (?)
0×0438 0×043b 0×0004 (?)
0×043c 0×043f 0×0004 unused (zeros)
其中，DOL就是游戏的可执行文件，FST就是文件分配表。
OK，想Patch DOL，做ASM Hack的话，DOL的位置就这么确定了。下面我们来说FST，修改替换游戏文件必须经过这个（当然你可以把文件位置硬编码到补丁里面，但是这样就无法处理经过减肥和压缩的GCM）。
FST格式：
开始 结束 尺寸 内容
0×00 0×0c 0×0c 根目录
0×0c … 0×0c 文件项
N项
… … … 字符串表，文件和目录名
FST文件项含义：
偏移 尺寸 内容
0×00 1 标志位，0:文件 1:目录
0×01 3 文件名，在字符串表中的偏移
0×04 4 文件偏移或者目录相对于父目录的偏移
0×08 4 文件长度或者内容数量（根目录）或者下一个目录偏移
GCM的关键格式我们都知道了，具体怎么操作呢？下面是Pascal伪代码（代码摘自Nitendo GameCube GCM Patch Tool v3.5 HyperIris）。
TFSTItem = packed record
ItemType: byte; //0 file; 1 dir
FileName: array[0..2] of byte; // Filename offset in string table
FileOffset: DWORD;
FileSize: DWORD;
end;
//读取FST信息：
Seek($0424, soFromBeginning);
Read(FstOffset, 4);
Read(FSTSize, 4);
//读取FST根目录
Seek(FstOffset, soFromBeginning);
Read(FSTRoot, 12);
FstItemCount := ToLeDWORD(FstRoot.FileSize);
//读取所有的FST数据
Seek(FstOffset, soFromBeginning);
GetMem(FST, FstItemCount * Sizeof(TFSTItem));
ReadBuffer(FST^, FstItemCount * Sizeof(TFSTItem));
OK，这样我们就可以在内存中直接遍历FST查找我们需要的文件信息了。
以上是纯技术讨论，其实有现成的工具（比如GC-Tool）可以提取替换GCM中的内容，但是我们的目标显然是直接修改GCM，编写自己的补丁。
有了打开GCM文件的钥匙，我们就可以一窥游戏的内容了。下面我们来说说GC数据文件格式，注意这些格式要么是硬件要求的，要么是任天堂官方SDK推荐的，大多数第三方会用自己的打包和压缩格式，处理这样的文件需要进行必要的二进制分析或者调试。
压缩格式：
yay0，yaz0：这是任天堂的传统压缩算法了，自N64时代就广泛应用，N64、GC、Wii，DS游戏中都可见到，处理的工具也很多，不多废话了。
cms：这个压缩格式在GCFE中使用，属于自定义压缩算法。
cmp：这个用于Metroid Prime，属于自定义压缩算法，在Metroid Prime 2/3中已不再使用。
文本格式：
bmg：常汉化DS游戏的会很眼熟，没错，基本上没什么区别。
字库：
bfn：常汉化DS游戏的会很眼熟，没错，基本上没什么区别。
图像格式：
GC、Wii硬件至少支持14种图像格式，其中游戏文件使用的是13种，如下：
I4 (4bit单色)
IA4 (4bit单色带透明通道)
I8 (8bit单色)
IA8 (8bit单色带透明通道)
CI4 (4bit索引)
CIA4 (4bit索引带透明)
CI8 (8bit索引)
CIA8 (8bit索引带透明)
RGB4A3
RGB5A1
RGB565
RGBA8
S3TC
以上各种在游戏中均有大量使用，具体解码方法，可以参考Dolphin-emu的图形插件。
但是汉化中，基本不会遇到修改索引颜色的图片。
好了，这样我们就可以拆开GC游戏，用CT之类的工具来折腾了。