【GBA、NDS、PSP】汉化基础教程——文字篇（一）by PGCG

守护￥云

汉化基础教程——文字篇（一）by PGCG

　　随着对汉化理论的逐步理解与掌握以及对经验技巧的掌握，本教程所涉及的内容也会渐渐加深、渐渐拓宽。前面几节相信大家已经懂得了如何修改游戏中的图片内容，这主要是借助现成的工具加上一点点耐心傻瓜化地修改来完成的。有很多对汉化抱有热情玩家都只能停留在修改图片上，其原因大家也能想得到。仅仅掌握了修改图片的方法也还远远不够，游戏发展到今天基本上没有哪个游戏的文字就纯粹是采用图片来存储的了，了解文字显示的核心至关重要。从现在开始接触的东西对大多数人来说才真正感觉到难度。希望大家既不要骄傲自大，也不用妄自菲薄，万里长城也不是一天建成的，既然大家对汉化有如此的热情就一定要对自己充满信心。
　　在教程的最开始就谈到了文字在游戏中是如何存储显示出来的：游戏文字信息通过将文字编码、文字点阵信息分离并保存到游戏文件中，显示文字的时候程序先读取表示句子组成文字的一序列编码，然后根据游戏自身独有的字模转换程序通过编码计算出字符点阵的物理地址，然后再通过一系列的显示程序把该字符点阵显示到屏幕上。


我们知道了基本过程后就不难猜想到，既然要修改文字我们还是可以通过修改点阵来实现。例如句子“Ｉ　ｌｏｖｅ　Ｃｈｉｎａ！”，可以把字符点阵“I”改为“我”；点阵“ｌ”改为“爱”；点阵“ｏ”改为“你”……以此类推。句子就被改为了“我　爱你，中　国！”，多余的字符就全部清除。理论上分析了，我们先来找个游戏进行一下实践——《光明之魂II》



我们就来修改一下图片上顶部出现的那句话，按照字面意思可以修改为“请选择一名角色”。通过我们前面所掌握的修改图片的方法很快就能找到这些文字的位置，用TLP定位到0x8DC068，这里就是第一 个字符“キ”的位置，我们可以看到该字符由4个TILE构成，排列顺序为[左上][右上][左下][右下]。



在前面就已经说过图片之所以会出现错位这并不是由于TLP软件的错误造成的（TLP永远都是顺序显示的），这个和游戏显示程序的设计有密切的联系，但具体为什么需要这样排列的这并不在我们讨论之列，我们需要做的仅仅是按照原先的顺序排列好修改后的字符就可以了（字符的描绘可以使用任何一款图像处理软件中的文字工具来制作）。




经过导出导入修改等一系列过程，这个字符被修改为了“请”字。其他的字符按照这样的方法依次修改，修改完后用VBA模拟器预览效果，可以看到这样的画面：




看来这样子做是相当成功的！见到了这样的成果你心情将会如何呢？

---

       高兴之余静下心来还是会发现一些问题，如果把“キ”改为“请”的话，游戏中所有出现了“キ”字符的地方都变为了“请”，但“キ”并不是“请”的意思。如果全都都照这样子修改的话，一两句还是可能实现，要是句子多了绝大部分句子就要混乱了。所以仅靠这样子的修改还不行，我们还得调整每个字符的排列顺序甚至出现的位置。我们再来看看字符显示的全过程，程序是先从文件中读取了句子文字的编码串然后再经过一系列程序才显示出来的，换句话说编码串就决定了字符的排列顺序，要改变文字的顺序就是要改变编码串中各个编码的顺序。例如：先假设01表示“Ａ”、02表示“Ｂ”、03表示“Ｃ”，句子“ＡＢＣ”对应的编码是010203，如果要改为“ＣＢＡ”的话我们就可以把“010203”改为“030201”。明确了这个道理，我们就必须找到句子对应的编码串在游戏文件中的具体位置，但我们事先并不知道每个字符对应编码，而且每个游戏的编码都不尽相同，所以也不可能根据经验来判断，缺少了这些关键的信息我们就无法搜索出编码串位置。于是我们的首要任务就是先找到一些字符的编码，然后就可以顺藤摸瓜测试出其他字符的编码。但问题是如何知道字符编码？这是一个巨大的难题。在开始找到“キ”字符后，留意一下就可以发现一些线索：基本上所有的文字点阵都保存在“キ”字符点阵附近的一大块区域内，而且字符和字符之间并没有其他杂乱信息，看来设计人员是把整个游戏出现的字符都放在了一起。那么这些点阵字符的首地址就很有规律了——公差为128Byte，因为1个4bpp的Tile占用的是32Byte的空间，一个字符需要4个Tile。前面也说过，编码是用来计算字符点阵的物理地址的。至于使用的什么具体公式我们并不用去在意他，我们可以导出一个抽象公式来理解：


点阵地址 = 字库首地址 + 偏移地址
偏移地址 = 比例常数 * 字符编码 + 偏移量

比例常数 = 点阵大小 * K
所以： 点阵地址 = 字库首地址 + 点阵大小 * K * 字符编码 + 偏移量
对于同一游戏来说公式中的字库首地址和偏移量都是一个常量，唯一的变量就是中间的一段，由此看来点阵地址和字符编码是成线性对应关系。而我们恰好可以查看得到等号左边的点阵地址。把上面的公式通过一些数学上的变形可以得到：


△点阵地址 可以写成△字符编号 * 点阵大小，所以又可以得到：（△字符编号就是两个字符点阵的序号位置差，单位为“1”）

△字符编号 可以轻易知道，而系数K在同一个游戏中是一定的，并且公式里的其他参数全都为整数。△字符编码 一定大于或等于 △字符编号，因而K小于等于1。点阵大小就是每个字符点阵所占用的空间，这个例子就是128。（还不至于哪个游戏设计者喜欢自我拔高到利用二次函数来计算吧-_-b）。只要能知道K的具体数值我们就能知道 △字符编码了，再接下来就可以通过相对搜索来得到句子的物理地址咯。

　　准备好一个相对搜索工具，比较好用的是汉化高人“阿一”制作的《增强差值搜索器》和一个《字模精灵组合器》，最后再理解一下上面的推导过程。这一节先到此为止。
小结：
　　本节开始正式涉及到文本文字的修改，内容逐步变得难以理解，光看不实践是绝对不行的。文本文字的修改要比图片修改更加的困难，很多时候都得靠灵活的方法才能对付。大家有了一定实践基础以后很容易犯迷糊，误以为每个游戏的文字都能按照这样的方法修改，我一直都在强调，游戏不可能一层不变。这一节中虽然提到了几个数学公式，如果你对数学不太了解，也不用去在意几个公式怎么得到的，只要你能知道地址和编码成线性比例，有这个意识就可以了。我在这儿之所以要这样提也是为了告诉大家要调动自己所掌握的其他相关知识来思考问题，一个人的知识结构应该是网状的。这不仅包括电脑相关知识，凡是能用上得都可以用上来，万一此路不通还可以通过其他知识换个角度来思考。细心的人也许会注意到“キ”字符修改为“请”字符后颜色数变少了，没有了蓝色。我来解释一下：对于大字符（一般来讲8*8的字符叫小字符，除此之外就算大字符）外观看上去比较粗大，如果只用一种主色再加上一种阴影色的话会使字符看起来有明显的锯齿，特别是对于笔划比较简单的字符（GBA可没有全屏抗锯齿功能哟）。所以游戏设计者会采用一些辅助色来对字符的拐角进行前景和背景的过渡。不过这对于笔划相对比较多的中文汉字来说用不用过渡效果并不是十分明显，如果再增加字符光滑的处理的话汉化的成本（主要是时间，时间就是金钱嘛）就太高了吧。除非你有特殊要求，否则就没有必要这么做了，一般都是采用一种主体色加阴影色在加背景透明色来做汉字字模了。