关于汉化NDS游戏

汉化是个很有技术难度的工作，如果你没有在GBA时代的汉化工作基础。那么，独立完成一个游戏的汉化，是很艰难的。

随便说说，我也参与过某组某游戏的破解，知道一些，就随便说说。其中引用了一部分资料

一般来说，就分几步：1、破解游戏 2、文本导出 3、图片导出 4、翻译 5、润色 6、测试

破解游戏例如哪里是字库，哪里是图片（分别对应那些图片），哪里是文本区，哪里是声效区……如果文件系统比较复杂的ROM，不同文件分别是什么内容也要进行判明。另外有的游戏不同文本对应不同字库，这些都是需要认真确认的内容。有的ROM可能有压缩过的内容，如果这些内容涉及汉化的需要，这时还需要进行解压和压缩的测试。一般这个阶段我是会准备几张大纸进行详细记录的，这样为以后的工作将带来很大方便。2 字库导出这个是关系到汉化可能性的最关键部分。一般游戏的字库有分完整字库和精简字库。完整字库里面包含了7000多个字符（其中6000多个汉字），而精简字库一般只有1000－2000个游戏里面实际运用到的字符。无论那个字库，由于日语汉字缺乏不少中文常用字，都必须修改，而精简字库更需要大改造，甚至扩容。后面会专门针对字库HACK进行讲解，此处暂时打住。3 文本试验汉化，就是用中文替换原来的日本语内容，所以需要对这个替换的可能性进行试验。当然，初步破解不一定要很正经的进行文本导出导入，或翻译修改，只需看看有没有修改的可能性就行。前面提到的不少教程都有涉及这方面的操作，可以仔细研究。4 图片HACK的主要就是图片拼组，色版处理等。另外一些需要汉化的关键图片（图片里面有需要汉化内容的）必须找出来。另外还可能需要做好色版导出，图片导出等准备工作。也可以进行一些图片修改的试验。如果上面的部分准备完成，并测试成功，那么恭喜，这个汉化项目已经成为可能。可以推进下一步工作了。

下一步就是学CT了

CT全称CrystalTile，是由天使组的Crystal在过去的tile工具的基础上不断改进的成果。可以说是汉化GBA/NDS游戏非常好用的工具。另外它还综合了差值搜索，LZ77解压，等不少有用的功能，而且还特意为汉化NDS游戏进行了优化。另外这个工具的版本还不断修正更新，我用的是5月中的版本，写本文的时候又更新了几个版本了。其实以前的TILE工具的一些操作在CT上面是通用的，那些工具都有一些网上的教程，但对于没有接触过的朋友，也作为CT这个新工具的介绍，所以我这里就专门简单介绍一下。下面就是CT的界面：①的区域是导航栏的主部分，最主要的是偏址，即偏移地址，另外还有颜色格式，颜色格式关系到能否正确查看ROM的图形部分的内容，汉化NDS游戏常用的是1bpp单色，GBA 4bpp，GBA 8bpp这几种（1bpp单色主要针对的是字库的内容）②的区域就是显示色版，关系到能否正确显示图形里面所对应颜色。可以在调色版菜单里面进行调整或回复默认。直接点击里面的颜色，可以进行直接修改。如果是非256色的色板，上部的横拉杆还可以读取总色版（256色）的不同部分来进行匹配。③的区域是TILE工具，可以进行简单的TILE修改，同时CT在这里还集成了通过码表生成字库的强大功能。(如果平时用不上TILE功能，可以隐去这个窗口腾出工作空间)中部的就是打开的ROM的内容了。现在ROM是以TILE模式打开的，也就是可以直接观察里面的TILE内容（字模，图形……）菜单栏下面是快捷工具栏分别是①导出按钮，这个按钮可以让CT导出选定的内容到一定格式的文件，常用的是将选定的图形区域内容导出为BMP文件，但CT的导出功能可不仅限于导出图片哦。具体的内容在图片H教程会进一步讲解。本篇只需有个大体概念就行了。②导入按钮，对修改好的图片，例如BMP图片，导入回ROM里面的指定区域。③16进制编辑器快速切换按钮，可以快速切换到16进制模式④LZ77解压按钮，对选定的LZ77内容解压⑤LZ77压缩按钮，将选定的内容进行LZ77压缩⑥将色版转换为16/32数据导入⑦将16进制方式存放的色版导出为PAL色版文件⑧对编码染色⑨应用码表开关其中④⑥⑦⑧⑨只能在16进制视图模式才可以使用。打开视图菜单，可以把工作ROM的视图转换到其他模式。下面我们切换到16进制模式，看看CT的16进制编辑功能。CT跟一般的16进制编辑器很像（虽然不及UE强大），但却结合汉化进行了优化。例如进行了编码染色。非常方便查看，有经验的美工，甚至可以直接通过被染色的编码马上就能找到色版数据的开头，进行色版导出（后面的美工教程会有进一步介绍）。另外在文本区域中间，也能很容易找到特殊控制符的内容（例如下面的例子中的F1FF等控制符就被染色为浅蓝色，与一般文字区别开来了）。另外一个很有用的功能就是直接套入码表来显示文本区的大体内容：一般NDS游戏对应的码表有两种分别是8140＝空格的标准Shift-JIS码表和0000＝空格的连续码表（码表的相关内容在后面的教程会进行介绍）。可以大胆地套一下来看看能不能找到文本区。例如超执刀就是用0000=空格那种码表，套入后，应用码表，就可以在CT的16进制模式大概看到文本区的内容。这对于解读ROM是非常必要的。另外CT还有一个很有用的功能就是NDS文件系统。通过这个系统能直观地看到NDS的文件结构，有的ROM甚至会把不同类型和用途的文件以更细致的方式存放，对于了解ROM的结构非常有用。此外在文件系统栏里面还可以分别对不同部分的文件进行导出和导入，分别分析和修改。CT还有不少强大的功能，待各位在运用中慢慢挖掘吧。总之我觉得开放这个工具的人，只要不是进行过非常规压缩和加密的ROM，大概能破解99％的GBA/NDS游戏了……二面用一个简单的例子来说一下CT的TILE操作。一般在CT里面发现大概图片后，通过调整窗口大小（快捷键SHIFT+方向，但最新版本修改了这个功能的快捷键，用新版本的用户请阅读新版本的说明），另外，缩放的数值建议用200左右进行作业（旧版本用1位数值显示缩放比例）。这样就可以调整至比较工整的情况。（下图已经进行了调整）但这时看到的颜色是不正确的，因为默认的色版不适配所有图形（正确来说一般都不会适配，但相对的，也比较醒目）。如果想比较好地观察，我建议自己准备一个黑至白的色版（具体色版建立方法留在美工教程说吧），这样图形就能排除颜色的干扰更容易发现，对于未能确定色版的时候是非常方便的。当然，要准备的分别是8bpp（256色）和4bpp（16色）两种，以适应不同格式的图片。好，回到上面，只要套入了正确的色版，那么图片就可以正常显示了。（当然对于ROM解读阶段，没有必要给每个图片套上正确的色版）但发现貌似有点瑕疵，那是因为地址偏移还未准确。用快捷键：CTRL+方向键左右可以微调地址偏移，这个操作非常重要。调整后，隐藏掉碍眼网格就能看到这个效果了。用上述的方法就可以大概了解ROM的一下大概构造了。结合NDS文件系统大概了解一下各个文件分别包含的是什么内容，关键是这个内容在ROM的那个地址。另外也得进一步分析各个内容的具体位置，准备几张大白纸，仔细记录好ROM的各个区域分别是什么内容，例如按地址位置顺序列出：XXXXXXXX-XXXXXXXX是大标题图，8bppXXXXXXXX-XXXXXXXX是小标题图，4bppXXXXXXXX-XXXXXXXX是人物全身像，8bppXXXXXXXX-XXXXXXXX是字库，1bppXXXXXXXX-XXXXXXXX是文本区XXXXXXXX-XXXXXXXX是音效…………这个记录非常重要，一方面可以方便你随时查找需要注意的部分，另一个很重要的作用是：对于未确定地址的内容，可以通过归类和排除法，快速找到其可能的位置。对于本文的内容，可以参看第一话介绍过的教程的相关部分，并进而学习一些文本，码表的相关知识。终于进入了有点技术含量的部分了………

GBA/NDS游戏一般是怎么显示文字的呢上里面提到了用CT套入正确的码表，在16进制模式，文本区就可以看见文本内容了。原理就是，ROM的文本区是用16进制代码来写的，例如上图中：“2年前の检查”对应的16进制就是000706f0行的CD00 CE0B 9B09 4701 3E06 1307这5组16进制编码。而码表就是表示CD00＝2CE0B＝年9B09＝前4701＝の3E06＝检1307＝查这样的转换关系的列表。游戏里面也是通过这样的转换关系，从字库挑取字符显示到屏幕上面的。如果把上面文本区编码改成CD00 CE0B CE0B 4701 3E06 1307游戏也相应会显示成：2年年の检查，这个也是汉化对文本修改的基础原理。（原文的“检”字不是简体的“检”字，为了说明方便我做了简化处理。）一般日文版游戏用的是Shift-JIS码表，一个完整的Shift-JIS码表从空格开始，标点，特殊符号，英文字母，平假名，片假名，日语汉字……例如8140= 8141=、8142=。8143=，8144=．8145=·8146=：8147=；8148=？8149=！814a=゛814b=゜814c=′814d=‘814e=¨……像上面这样的一个对应关系存放的TBL文件（可以用WINDOWS的记事本打开和编辑）而之前也说过，一般完整的Shift-JIS有2种主要的表示方式，如下图，分别是从8140＝空格和0000＝空格开始的两种（0000＝空格严格来说不是Shift-JIS，而是在Shift-JIS的基础上重新进行自定义的编码）。一般完整的Shift-JIS码表汉字部分是以“亜”开头，以“熙”字作为结束（最完整的是以“黑”字结束，也就是“熙”后面还有一段，但一般情况下因为不是常用字，不少游戏就去掉“熙”字后面的部分了）。下面是这两种码表的分析：这样对比不难发现一个问题，8140＝空格开始的那种码表，并不是连续的，而是跳过了XX00-XX3F、XX7F、XXFD、XXFE、XXFF（观察第一个码表中间框住有空行的部分）。而第二个码表是完全连续的。为什么呢？相信只要多观察几个文本区编码就会发现问题了。对于第一个码表的文本，跳过这些区域可以有效防止错位搞混的现象，另外也可以留出编码供半角字符，控制符等使用。而第二种码表的控制符则多数以FF00之后的编码作为控制符。上面说的是导出文本用的码表。只要能套上一个正确的码表就能把文本部分导出来了。但因为翻译后，不一定会（应该是“一定不会”）用上或只用上原来的字，因为汉化翻译后会用上很多原来字库没有的汉字（例如很多拟声词的字日语是没有的，例如吗，啦，嗯……），而且日语汉字多数是繁体字，要做简体版基本要把字库里面的字改成简体。那么翻译后要用新的字怎么办呢？最简单就是在原字库里面添加新字，但是如果只是添加就太浪费空间了，因为翻译后很多原来的字根本用不上，例如完整的Shift-JIS字库里面有6000多个汉字字模，而一般正常翻译之后，实际使用的汉字字模约2000－3000而已，汉化后因为内容跟原来不同，可以在原字库的基础上全部替换成需要用上的字模就行了。但是问题又来了，这些新的字模写进去后，怎么把它跟文本区的编码挂钩呢？这就需要用新的码表方式，把字库字模和文本区的编码重新对用上，这就需要重新编辑一个新码表。简单举个例子。例如上面的“2年前の检查”，汉化后变成“2年前的检查”，“的”字的字模我必须找一个位置放它，例如原来码表是4E03=亜，翻译后用不上这个繁体的“亜”字了，我就在字库原来“亜”的位置把它改成“的”字，然后把码表的对应关系改成4E03=的，跟着导入文本的时候，把原来的编码行“2年前の检查”的CD00 CE0B 9B09 4701 3E06 1307改成“2年前的检查”：CD00 CE0B 9B09 4E03 3E06 1307。那么游戏就会从原来4E03=“亜”的地方提取出现在修改后的“的”字。而这个新的码表和字库对应关系就是导入文本用的码表，也就是修改后的码表。这就需要重新编辑一个码表了。以上就是对码表的简单介绍，有个大概概念后下面转入字库部分，先简单了解一下字库和码表的关系。上一话讲了最基础的ROM解读，那么字库一般在ROM里面是什么样子的呢？下面就是一个例子：这个是超执刀的小字模字库库，看右边信息就可以看到字模是8X8以下的，用的是1bpp（2色），在游戏中的作用主要是用以标注某些专用名词的上标。而正文的字库是16X16的1bpp（2色）。小技巧：一般判断字库字模用的模式1bpp（2色），2bpp（4色），4bpp（16色），8bpp（256色），可以在游戏里面观察字体，如果是带阴影或边缘模糊（抗锯齿）的，一般就是4色以上的了。另外，如果字库附近有色版信息，从色版的结构（例如是2色，4色还是16色的色版）也能大概判断出字模的显示模式。

图片方面的话，以应援团为例说明下：这个少数游戏的会比较艰难

应援团里的图片文件一般被分成了3部分:

TILE文件:也就是主要的图形文件

MAP文件:控制TILE摆放的,类似图片中的文本

PALETTE文件:调色板文件

以上3个文件都是压缩后的.对应的文件扩展名分别是:

NCGR_ NSCR_ NCLR_

图片导出:

首先,如果有调色板压缩文件.NCLR_,就先把这东西处理成可用的PAL文件.

方法是,用CrystalTile打开此压缩文件,在十六进制编辑器(视图)状态下,选择LZ77数据搜索(工具),点全文搜索,可能找到很多个,然后点解压-->全部解压,应该只能解出一个文件,再用CT打开解压后的文件,点一下0x28的地方,选则GBA 8BPP,在调色板选项里选转换成调色板,然后再点导出软件调色板(调色板),就可以转换成PAL格式了,不过此种方法和下一种方法转换的PAL文件的第0x10和0x11两位不同,不过这两个字节和颜色数据无关,所以两种方法都可行.

另一种烦琐的方法是,用CrystalTile(CT)打开此压缩文件,在十六进制编辑器(视图)状态下,选择LZ77数据搜索(工具),点全文搜索,可能找到很多个,然后点解压-->全部解压,应该只能解出一个文件,将解压的文件改成 p.dmp(扩展名是这个方便,文件名随意),之后用VBA随便打开一个gba文件(其实随便,我就自己生成了1个空文件,把扩展名改成了gba),打开内存查看器,点读取,把刚才那个p.dmp选上,然后地址填4FFFFD8(解压后的文件是从0x28处开始是颜色信息),关闭内存查看器,打开色盘查看器,点保存BG,这样就把 NCLR_ 文件变成了我们常用的 PAL 文件.

接下来,把 NCGR_ 文件解压,比如起名 1.bin ,然后把 NSCR_ 文件解压,比如起名 2.bin,然后自己写个批处理文件(用记事本写一个内容为 copy *.bin /b out.bin,然后把 txt 改成 bat 就可以了).运行,这两个解压后的文件就合并到一起了.用UE或其他十六进制编辑器打开这个合并后的 out.bin ,找到RGCN,其中记录R的地址+0x30为TILE地址,找到RCSN,其中R记录R的地址+0x24为MAP地址.

最后打开CrystalMap,在TILE地址和MAP地址相应填好,BG宽度一般是256,高度一般是192(实际是256,从MAP数据文件的大小可以算出来MAP数据部分为2048字节,也就代表1024个TILE,横是32,纵也是32,所以高和宽都应该是256,但是DS的屏幕只有256x192,其余的显示不出来,这是在写导入部分时候发现的,汗),这两个数据不同的图可能不同.颜色里加载刚才转成的PAL文件,颜色是16色模式还是256色模式要根据具体图片而定,最后选上MAP拼图(编辑),OK,最后一步,导出(编辑)图片.

某些图片没有NSCR_文件,那样一般是16色的,没有MAP数据,就需要慢慢手动拼了(感觉是OAM拼图,不过没有研究过OAM数据).

DS图片的导出方法大致都是这样.

---------------------------------------------------------------------------------------------------------

改后导入:

一般来说,图片的导入就是导出的逆过程,还是像导出的时候将图片用CM显示出来,然后选导入(编辑),之后把文件再拆成两个文件,按TILE数据和MAP数据文件的文件头拆就可以,然后分别压缩,改成原来的文件名,替换掉原文件.

不过这个导入过程和上面的导出过程的关系就像求积分和求微分一样,导出是简单的,导入就要相对困难一些.所以最好是分析文件里的数据信息:

发现解压后的TILE文件的文件头的那48字节为:

52 47 43 4E FF FE 00 01 XX XX XX XX 10 00 01 00

52 41 48 43 YY YY YY YY ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ

00 00 00 00 00 00 00 00 MM MM MM MM 18 00 00 00

其中XX部分为从地址0h开始算,下面的字节数,也就是文件大小,高位在后,YY部分为从地址10h开始算,下面的字节数,也就是文件的大小-10h,即YYYYYYYY = XXXXXXXX - 10h,ZZ部分未研究明白,汗,MM部分为从地址30h开始算,下面的字节数,也就是文件的大小-30h,即MMMMMMMM = XXXXXXXX - 30h,这样就可以重新自己写一个TILE文件.

如果图片是256x192大小的256色图片,那么TILE文件的大小应该为256x192+48=49200(C030),我们可以写一个这么大的空文件,然后把文件头改为

52 47 43 4E FF FE 00 01 30 C0 00 00 10 00 01 00

52 41 48 43 20 C0 00 00 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ

00 00 00 00 00 00 00 00 00 C0 00 00 18 00 00 00

ZZ部分和原TILE文件一致,然后用CT打开这个只有文件头的文件,把窗口改为256x192的大小,偏址设为30(此处是十六进制),然后直接导入修改后的BMP文件,保存,未压缩的TILE文件就制作完毕了.

然后再来看MAP文件里的文件头数据:

52 43 53 4E FF FE 00 01 XX XX XX XX 10 00 01 00

4E 52 43 53 YY YY YY YY NN NN PP PP ZZ ZZ ZZ ZZ

MM MM MM MM

这里的XX部分,YY部分,MM部分的意思和TILE里的是一样的,NN NN 为图象的宽,PP PP 为图象的高,ZZ部分也是未弄清的,理论上MAP文件的大小应该为(256/8)x(192/8)x2+36=1572,但发现原ROM里的是2084,原来ROM里的MAP数据是256x256的,也就是说把图片按256大小的方型处理了,在游戏显示的时候只显示最上面高192的部分,这样写一个2084(0824)大小的文件,文件头直接把原来的COPY过来就可以了,然后从24h开始写00 00 01 00 02 00 03 00...一直写到617h就可以了,这样新的MAP文件就做成了.

最后说一下压缩问题,DS不是有个Wi-Fi吗,那我的办法就是Wi-LZ77(伪压,这回是真成的伪压缩,采用压缩格式,但是没有起到实质性的压缩,反而是文件变成了原来的1.125倍再多4字节,再汗).

具体方法就是新建一个空文件,先向该文件写入10(LZ77压缩的标志),然后再向其中写入待压缩文件的大小(3字节,高位在后),然后向文件里写一个00,从待压缩文件里读取8字节,写入此文件中.循环写00再写8字节的过程,直到把待压缩文件都读完,这时生成的文件就是伪压缩后的文件.改完名称,放回原位置,应该就可以用了.

原理:

先说调色板,正常256色PAL格式的调色板,颜色数据是从0x18开始,每四字节代表一个颜色,最后一字节为00,前3字节分别代表R(RED),G(GREEN),B(BLUE),每个字节的范围是0x00-0xff,但是GBA和DS的调色板是用两字节来表示颜色,算法是分别将[B/8],[G/8],[R/8]转换成二进制,取后5位,连成一个15位的数,然后在前补一位0,最后转换成十六进制,高位在后.

注:[]是取整函数,所以GBA和DS上两个最相近的颜色的RGB值最小差8,做成渐变效果非常不理想,大多都可以看出颜色的层次.

例:正常256色PAL格式的调色板里的颜色数据为 00 18 28 00, 其中第一个 00 代表 R:0, 18 代表 G:24, 28 代表 B:40, bin([B/8])=bin(5)=00101, bin([G/8])=bin(3)=00011, bin([R/8])=bin(0)=00000,然后连成一个16位数是: 0001010001100000, 转成十六进制是 0x1460, 高位在后就是 60 14, 这就是在GBA或DS ROM里看到的数据.

DS ROM里的NCLR文件是从0x28开始是颜色数据.

再说说TILE数据和MAP数据,这里的TILE是只8x8的,每个TILE就像一个字模,而这些TILE的生成原理也是像生成码表一样,一般在图片里先出先的在前面,依次排下去,有和之前TILE相同,就跳过,这样一幅图就用了较少的TILE记录下来,同时生成他们的排放顺序,也就是MAP数据,一般MAP数据是双字节(有的是单字节),一般高位在后,有时高位代表特效(比如水平翻转,垂直翻转等,有兴趣的朋友可以自己研究一下,不过貌似GBA系统参考里有),特效CM都能正常显示出来,不过改完了,导入时CM只会处理双字节的低位,有些特效代码就要自己手动清00了.

其实我一直把TILE数据和MAP数据按字和文本的关系来理解,这样很易懂,就像我记定理时总爱往几何上靠,这样记得深刻一样

那么，到这里，破解就完成了。

下面就到翻译了，这个没什么好说的。个人汉化的话，基本是边翻译边润色。直接把文字扩容或缩减到对应的部分。

上面那些都没问题了的话，导入更是小问题了。

另外，推荐LZ个入门汉化一些容量小破解简单的游戏，可以试试太空侵略者

就是破解简单，文本量也不大。

LZ先学习性的汉化一个，再考虑难的：

偶自问有一些基础，但是在尝试破解诸如魔界战记之类的，还是遇到很多麻烦。个人实在没有能力精力。

我学汉化时在 A9VG学的，你也可以去多看看，有很多具体的汉化实例。

另外，ACG和星组都是技术实力很强的组。LZ这样说的话，感觉HH游戏很简单一样。不喜欢就玩日文版本去，没人勉强你

修改图片文字同样需要破解，同样需要导出文本图片，和汉化一个游戏是一样的道理，OK？