夜行侦探 EVE burst error 游戏文件分析（十）

np2kai / retroarch / eve / pc98 / dosbox-x

原来觉得该说的，基本上都说完了，随着汉化工作的进行，好像又可以凑一篇出来，作为后记

目录

本系列基本完结，以下是目录供快速翻阅：

  1. 启动、GDT 文件分析一：19 个函数
  2. GDT 文件分析二：ghidra 偏移量、读取、初次绘画
  3. GDT 文件分析三：多次读取、偏移量、调色板
  4. GDT 文件分析四：完整解开及遗留问题
  5. 游戏文本解码
  6. 汉化方案制定
  7. 游戏文本编码
  8. 汉字日文编码、字库、以及第一个汉化文件
  9. 配置一个汉化 demo
  10. 手机游玩、程序文字汉化

Neko Project II Kai

现在很多人家里可能压根儿没有电脑，但是手机是人手一部起码， 所以如果能在手机上玩 PC98 游戏，那想必是方便不少， 而且这样依赖我也可以利用不在电脑边的时间来测试汉化成品。 研究了一下，还真有这么一个东西叫 Neko Project II Kai：

这是一个可以在 RetroArch 中加载的核心，主要目的就是为了模拟 PC98 游戏， 安装了这个核心，配置好 BIOS，我们就可以直接加载 hdi 文件在手机上玩起来了。

而在配置 BIOS 的过程中，我发现，NP2Kai 对日文字库的模拟方式与 DosBox-X 相比， 不能说是毫无关系，只能说是完全相同，都是一个单色 BMP， 而且我们可以完全沿用前面的 FREECG98.BMP，改成 NP2Kai 使用的名字， 放在 BIOS 目录中即可：

这样我们就有了一个挂了伪中文字库的 NP2Kai 来玩中文版的 EVE 了：

看粉红色的框图，可能熟悉的朋友可能猜到，我的小次郎剧情已经卡关了， 现在需要推进玛丽娜的剧情。

基本上，我是这样做汉化的，从菜单进入游戏的话，小次郎的一个场景是 A01.CC， 玛丽娜是 B01.CC，先汉化这个场景，然后在 DosBox-X 替换原场景文件， 然后进 RetroArch 测试，根据剧情推进，到了未汉化的场景必然就会出现乱码， 这时再退出来，找到对应场景文件再汉化，以此类推。这样的好处是， 测试的时候不需要在电脑前，可以利用碎片化的时间。

AGS.EXE

AGS.EXE 是游戏的执行文件，因为看上去这个名字和游戏完全无关， 我原本以为这是游戏引擎的名字，那么如果是游戏引擎的话， 那么程序内应该是不含有游戏相关的内容的，这也是我一直以来的假设。

不过，现在这一点已经被打破了，起因来自游戏的读档、存档的界面：

这有两个问题，「井肌虾」我已经习惯了，是小次郎的乱码， 玛丽娜因为日文假名的 shiftJIS 编码与 gb2312 是相同的，所以还看得出来。 另一个问题就不太能忍了，就是存档文件的排版乱了，已经遮挡到了底框。

为什么排版乱了，我的推测是因为游戏没有考虑千年虫的问题， 现在的年份被显示为 124 年，多了一位，所以造成了排版错乱。

怎么解决这个问题，我的思路是这样：124 想要显示成 24， 需要修改程序逻辑，先把年份对 100 取模，但是这个估计会比较困难， 我也没有这方面的经验，那不如换个思路，减少一下其他字符串的长度， 我的想法是，把「小次郎」换成「天城」，玛丽娜换成「法条」， 这下字符串长度应该够用了。

那么接下来要定位「小次郎」三个字是从哪里读出来的，过程不太复杂，我简单说明一下， 如果有感兴趣的朋友，可以有思路上手：

  1. DOSBox-X 中到读取进度的界面，对读取文件下断点，点击读取进度后，进入断点， 开始记 log，这个不多，十万条以内就显示出来了。
  2. 「小」字的 shiftJIS 编码是 8F AC，我们搜 AC8F，就可以找到在内存中的位置：

  1. 通过 BPM 断点，寻找内容是从哪里复制过来的，这个过程会有多次， 也就是程序中是从 A 复制到 B 再到 C 这样，而我们要从 C 一直找到 A

最后我们发现，最终的源头地址，是在程序执行时写入的，那就很清楚了， AGS.EXE 中有字符串「小次郎」。

基于这一点，我们用 ImHex 查看程序的字节码，就可以找到程序中的字符串了， 一般这些字符串都会定义在程序末尾：

接下来我们就可以按汉化脚本的思路来了，首先简单翻译为中文， 然后生成中文的「ShiftJIS」编码：

running 1 test
未使用: [97, b2, 95, b7, 9a, 62]
天城: [96, ea, 8a, 66]
法条: [8c, 47, 96, f3]
继续游戏: [8e, ca, 98, f6, 9a, 6d, 98, 56]
游戏结束: [9a, 6d, 98, 56, 8f, 81, 95, f6]
真的结束: [9b, 86, 8b, 63, 8f, 81, 95, f6]
回到开始: [8e, 77, 8b, 5c, 90, 49, 95, ba]
取消: [94, 9f, 98, 9b]
test cc::test::gb_text_encode ... ok

然后把内容换到程序中即可，注意我们换进去的内容不能超过原始字符串的长度， 这样会造成程序指针的错乱，而译文比原文短的时候，处理也很简单， 不足的部分都填 00 即可。

字符串替换完成后，我们就可以去游戏中试一下了：

非常完美。

结语

好了，解决了移动端的运行，以及程序的中文化， 这个系列的技术部分我想应该是完全结束了， 最后剩下的部分可能只有完全汉化后的一个宣告了，那么我们到那个时候再见吧。

后记

有仔细阅读第九篇的读者， 应该知道这个系列是真的结束了，没有仔细阅读， 但是依然关注汉化进度的朋友们，请再仔细阅读第九篇。写第一篇的时候是四月底， 现在中秋也已经过了，不过整个工作是八月底结束的，这样算起来， 第一个月完成了文字部分的解码和编码，确定了实施方案。 接下来三个月就全是文字汉化的工作了，说来这个游戏的开发周期也只有四个月， 当然了，虽然花了不少时间，我也不是这四个月全扑在这件事情上，算个巧合吧。 中间有时还有 AI 的不配合，比较常见的是调用配额用完，相当于翻译说，我下班了， 咱们今天就到这里吧，于是我明明腾出了时间，但是却没办法做。还有一种情况， 就是有些内容翻译会拒绝工作，什么内容相信大家猜得出来，这种就比较麻烦， 委婉一些的，可以通过拆分来解决，露骨的，那只能借助一般翻译软件连蒙带猜了。 所以如果有朋友对汉化质量不满意，这是可以理解的，不过我确实能力有限， 如果有比较专业的朋友想来试试，也可以联系我。

好了，这里真的是最后了，作为一个玩家，我解开了一个心结，作为一个汉化者， 希望可以帮到有兴趣的玩家，我的汉化方法很奇怪，但是我依然觉得， 跟着我的思路一路走来的朋友会理解为什么我最终选择这样做， 而这个思路应该也适合其他 pc98 游戏。那我们下个系列再见。