Wonders Swan卡带ROM游戏翻译指南：以《魔卡少女樱》为例的图形、文本和代码修改挑战

Hilltop

光盘与卡带游戏的翻译挑战对比 [00:00:22]

视频开篇介绍了卡带ROM游戏翻译的特殊性，并与作者之前主要从事的光盘系统游戏翻译进行对比。

光盘系统的数据访问 [00:01:28]

• 文件需加载到内存 [00:01:33]
  • 系统内存有限，内容需频繁进出 [00:01:42]
• 数据以扇区存储 [00:01:53]
  • 最小数据单位为800字节的扇区 [00:01:55]
• 文件访问方式多样 [00:02:11]
  • 可通过标准目录系统访问 [00:02:11]
  • 也可通过文件起始扇区（LBA）或时间戳直接访问 [00:02:16]

    

卡带系统的独特性 [00:02:29]

• 处理器限制与游戏尺寸增长 [00:02:50]
  • 早期低规格系统处理器无法同时访问所有ROM数据 [00:02:53]
  • 游戏尺寸增长快于芯片处理能力，需要特殊技术 [00:03:05]

    

• 内存分区：Bank概念 [00:03:31]

  

  • Bank的物理结构与大小 [00:04:02]
    • ROM被分成固定大小的Bank（Wonders Swan为0x10000字节） [00:04:11]
    • 游戏数据不一定填满每个Bank，导致未使用的空白区域 [00:04:18]
    • Bank可包含代码、图形、声音等任何类型的数据 [00:04:38]

      

  • Bank寻址与切换 (Bank Addressing and Switching) [00:04:48]
    • 寻址、切换与Mapper [00:04:53]
      • 寻址：为Bank分配一块内存地址，使其可被CPU访问 [00:05:53]
      • Bank切换：将当前Bank换出，将新的Bank映射到内存地址块 [00:06:13]
      • Mapper：执行Bank切换的逻辑/硬件 [00:06:16]

- Wonders Swan的Bank结构 (C0-C3) [00:06:22] - Wonders Swan有四个Bank：C0到C3 [00:06:24] - C1保留用于RAM，不可用于ROM [00:06:25] - 每个Bank占据特定的内存地址范围（例如C1占用10K-20K） [00:06:33] - C0是“宽”Bank，占据40K-100K，但有特定限制 [00:06:50] - 寻址示例与只读特性 [00:07:00] - 游戏需访问ROM中0x110000的数据块时，Mapper会将其映射到可用的Bank（如C3）的内存地址（如30K） [00:07:02] - ROM Bank通常是只读的，RAM Bank可读写 [00:08:00] - Bank切换的静态行为 [00:08:36] - Mapper的行为是预先设定而非动态的 [00:08:52] - Bank中的数据，如指针，会假设其最终将被映射到的地址 [00:08:59]

Wonders Swan指针 [00:09:08]

• 指针结构与小端序 [00:09:21]
  • Wonders Swan指针长4字节，包含5个不同的十六进制数字 [00:09:24]
  • 第一个数字对应Bank，后三个数字是内部偏移，中间三个数字通常为零 [00:09:31]
  • Wonders Swan系统采用小端序存储字节 [00:09:55]

    

数据查找：指针表 [00:10:21]

• 无文件目录系统 [00:10:33]
  • 卡带ROM不像光盘游戏那样有标准化的目录结构 [00:10:35]

    

• 通过指针表定位数据 [00:10:40]
  • 需要查找指针表，这些表包含指向文件数据的指针 [00:10:40]
  • 指针表可能包含标题、模式和元数据，以更好地理解目录 [00:10:55]

    

图形数据分析与替换 [00:11:11]

翻译游戏需要找到并编辑文本和图形。本节从图形入手，因为对图形的理解是理解文本的基础。

早期与后期90年代的图形差异 [00:11:29]

• PS1/PS2：位图与调色板 [00:11:31]
  • 图形通常是像素矩阵，其索引值指向颜色查找表（调色板）中的条目 [00:11:41]
• Wonders Swan (及NES/GB)：图块与图块地图 [00:11:51]
  • 对于早期和低功耗硬件，位图图形占用空间过大 [00:11:54]
  • 采用图块地图（Tilemap）概念，将图像分解为小的可复用图块 [00:12:06]

    

图块地图（Tilemap）详解 [00:12:16]

• 图像分解为8x8图块 [00:12:42]
  • 不存储每个像素的颜色，而是将图像分解为8x8像素的图块 [00:12:42]
  • 维护一个包含所有独特8x8图块的图块库 [00:12:48]
  • 图块地图记录每个8x8图像块对应的图块索引 [00:12:56]
• 数据效率：1/64空间占用 [00:13:31]
  • 这种方法只存储图像的1/8分辨率，即总大小的1/64 [00:13:34]
  • 本质上是一种基于字典的压缩形式 [00:13:46]

    

    

图形存储示例：人物肖像 [00:14:05]

• 指针表结构解析 [00:14:41]

  • 图形Bank的指针表包含指向图块地图图形和精灵图形的指针 [00:14:45]
  • 图块地图图形由一个包含图块列表、地图列表和调色板列表的“三元组”指针组成 [00:15:07]
  • 列表通常以多个空条目终止 [00:15:29]

    

• 图块列表 (Tile List) [00:15:47]

  • 指针表中的第一个指针通常指向一个包含一个或多个图块集的列表 [00:15:49]
  • 图块集前面有一个2字节的值，表示该集中图块的总数 [00:16:20]
  • 在图块查看器中，可以直接看到图块数据，但缺少顺序和正确的调色板 [00:16:30]

    

  • 图块数据格式 (交错平面格式) [00:16:52]
    • 图块数据以交错平面格式存储，每个像素2位，每个图块16字节 [00:17:02]
    • 奇数字节存储第一个平面（像素的第0位），偶数字节存储第二个平面（像素的第1位） [00:17:08]
    • 两个平面合并，为每个像素提供0到3的值，决定其颜色 [00:18:08]

      

• 图块地图列表 (Tilemap List) [00:18:23]

  • 图块地图以列数和行数作为头部信息，代表图像1/8的分辨率 [00:18:29]
  • 每个图块由一个2字节的值表示，是图块集中相应图块的索引 [00:18:53]

    

  • 视频中出现图块ID远大于图块集数量的困惑 [00:19:31]

    

  • 图块转置（Tile Transposition） [00:20:02]
    • 效率优化：翻转图块 [00:20:07]
      • 硬件可以水平、垂直或同时翻转图块，这意味着一个图块可以显示四种不同方式 [00:20:07]
      • 这提高了效率，减少了需要存储的独特图块数量 [00:20:16]
    • 翻转标志位 [00:20:38]
      • 图块地图中的每个图块索引的2字节值，其高两位用于存储翻转标志 [00:20:38]
      • 0表示不翻转，1表示水平翻转，2表示垂直翻转，3表示同时翻转 [00:20:41]

• 调色板列表 (Color Palette List) [00:21:00]
  • 单色系统中的复杂性 [00:21:06]
    • Wonders Swan虽然是单色系统，但调色板处理相对复杂 [00:21:08]
    • 每个调色板是2字节，包含4种颜色，每种颜色是3位色调值，并填充1位 [00:21:15]
    • 颜色值范围0-7，0为白，7为黑，1-6为灰色 [00:21:28]

      

  • 全局阴影查找表 (Global Shade Lookup Table) [00:22:08]
    • 调色板中的颜色值实际上是指向一个全局的4位阴影查找表中的指针 [00:22:10]
    • 该表包含8个值，范围0-15，在游戏运行时动态控制 [00:22:13]
    • 这使得系统可以动态调整灰度色调和实现图像明暗效果 [00:22:21]

      

  • 透明色处理 [00:22:53]
    • 透明度在运行时启用，无法通过静态数据判断 [00:23:08]
    • 观察到透明图像的调色板通常在第一个槽位有重复颜色 [00:23:13]

      

图块、图块地图与调色板的组合 [00:23:33]

• 图像重构过程 [00:23:40]
  • 结合图块集、图块地图和调色板，可以重新构建完整的图像 [00:23:40]

    

• 图块集的复用性 [00:23:49]
  • 相同的图块集可以与不同的图块地图结合，生成不同的图像 [00:23:51]
  • 这解释了为什么通常只有一个图块集和调色板，但有多个图块地图 [00:24:08]

    

精灵（Sprites） [00:24:27]

• 与图块地图的区别 (X/Y位置与图块ID) [00:24:35]
  • 精灵地图存储图块ID和每个图块相对于“热点”的X、Y位置 [00:24:38]
  • 这意味着精灵图块无需对齐8x8网格 [00:24:49]
• 主要用于动画和非网格对齐图形 [00:24:54]
  • 图块集和调色板的工作方式与图块地图相同 [00:25:01]

    

图形替换算法 [00:25:10]

• 分解、编码、匹配与添加 [00:25:27]
  1. 将新图像分解成8x8图块 [00:25:27]
  2. 对每个图块： a. 根据调色板进行编码 [00:25:36] b. 如果该图块或其任何转置版本已存在于图块库中，则输出其ID和翻转标志到图块地图 [00:25:40] c. 如果不存在，则将其添加到图块集，记录所有四种转置，并输出其ID和翻转标志到图块地图 [00:25:56]

文本数据分析与修改 [00:26:11]

文本处理是翻译工作的另一个核心部分，其复杂性常常源于字体特性和编码方式。

字体结构 [00:26:19]

• 16x16字形，由四个图块组成 [00:26:26]
  • 游戏字体中的每个字符是一个16x16的图形，由4个8x8图块组成 [00:26:26]
• 需要添加英文字符 [00:26:32]
  • 原始字体没有小写英文字符，需要修改 [00:26:38]

    

文本存储 [00:26:42]

• 指针的指针（char**）结构 [00:27:36]
  • 文本数据以多级指针结构存储，即指向字符串指针列表的指针 [00:27:36]

    

• 对话行解析 (角色肖像、文本、终止符) [00:28:37]
  • 字符串的第一个字节控制显示哪个角色肖像 [00:28:37]
  • 文本内容在中间，FF FF是终止符 [00:28:52]

    

字距调整（Kerning）与变宽字体（VWF） [00:29:06]

• 游戏动态计算字符宽度 [00:29:41]

  • 令人惊讶的是，游戏不是通过预计算的查找表，而是通过逐像素扫描字符来动态计算字距 [00:29:46]

    

    

• 文本编码 [00:30:06]

  • 按宽度分类的字符ID [00:30:14]
    • 字符ID基于其在字体中的位置，且根据字符宽度分为不同范围 [00:30:14]
  • 单字节与双字节字符 [00:30:36]
    • 0到D1（红色区域）的字符宽度大于8像素 [00:30:25]
    • D2到F9（绿色区域）的字符宽度等于或小于8像素 [00:30:31]
    • 紫色区域（FBXX或FCXX开头）为双字节字符 [00:31:01]
  • 控制码（空格、换行、终止符） [00:30:42]
    • FA：全宽16像素空格 [00:30:42]
    • FD：8像素空格 [00:30:46]
    • FE：换行 [00:30:51]
    • FF：终止符 [00:30:55]

      

• 字距调整的限制 [00:31:25]

  • 只有D2-F9范围（约40个字符）允许8像素宽或更窄的字符 [00:31:30]
  • 40个字符不足以容纳英文大小写字母和标点符号 [00:31:48]
  • 游戏对16像素宽字符的字距调整扫描仅限于右半部分，并假设它们至少9像素宽，这阻止了将更窄的英文字符放入该范围 [00:32:00]

    

调试与汇编代码修改 [00:32:27]

为了解决文本渲染的局限性，需要进行调试并修改游戏的汇编代码。

Wonders Swan CPU架构 [00:32:33]

• 16位NEC V30 MZ，Intel 8086变体 (x86) [00:32:48]
  • Wonders Swan的主CPU是16位NEC V30 MZ，是Intel 8086的变体 [00:32:48]
  • 令人惊讶地与现代x86架构相关联 [00:33:08]

    

调试方法 [00:33:23]

• 使用读取断点定位文本函数 [00:33:25]
  • 在文本显示前设置读取断点，可在调试器中定位文本函数 [00:33:27]
• 使用Mason调试器 [00:33:33]
  • 强大的调试模拟器Mason极大地简化了调试工作 [00:33:33]
• 修改字符宽度判断常量 (D2值) [00:33:47]
  • 追踪文本函数发现字符字节与D2的直接比较 [00:33:47]
  • 降低该常量值即可扩展细体文本的字符范围 [00:33:52]

    

游戏文本渲染机制 [00:34:06]

• BG0和BG1两层背景图层 [00:34:20]
  • 系统可渲染BG0和BG1两个背景图层，它们本身是图块地图 [00:34:20]
  • 两层图层与精灵合并，创建最终游戏画面 [00:34:28]

    

• 动态生成和混合新图块以渲染文本 [00:34:52]
  • 由于字距调整，游戏无法直接使用字体图块 [00:34:55]
  • 游戏会动态生成和混合新图块，以创建文本作为图块地图，这些图块可能包含来自不同字形的像素 [00:35:01]

    

修复错误 [00:35:32]

• Bug 1：图块地图组装时的末尾图块损坏 [00:35:54]

  • 原因：游戏对字符最小宽度做假设 [00:36:04]
    • 游戏在处理换行时，如果多个极细字符共享最后一个图块，会写入错误的图块数量，导致文本框中出现损坏的图块 [00:35:54]
    • 解决方案：修改逻辑，使其不再假设字符的最小宽度 [00:36:21]

• Bug 2：文本框清除逻辑错误 [00:36:31]

  • 原因：只清除了20个图块而非21个 [00:36:39]
    • 文本框实际宽度为21个图块，但清除逻辑只清除了20个图块 [00:36:31]
    • 导致文本框最右侧的图块未被清除，残留前一行的内容 [00:36:51]
    • 解决方案：修改汇编指令，使其清除21个图块 [00:37:16]

      

• Bug 3：空格字符处理逻辑 [00:37:22]

  • 原因：游戏只支持8或16像素宽空格 [00:37:27]
    • 游戏简化了空格字符的逻辑，只支持8或16像素宽的空格 [00:37:27]
    • 无法正确处理自定义的更小宽度空格，导致“片段字节”（fragment byte）未更新 [00:38:04]
  • 解决方案：创建替换函数以支持任意宽度空格 [00:38:18]
    • 创建一个自定义函数来处理任意宽度的空格，并确保正确更新“片段字节” [00:38:18]

      

文本空间查找与最终结果 [00:38:31]

英日翻译通常面临文本长度增加的问题，需要寻找额外的存储空间。

卡带ROM的文本空间优势 [00:38:47]

• 利用“大Bank”中未使用的空间 [00:38:55]
  • 卡带ROM游戏在这方面比光盘游戏更容易 [00:38:49]
  • 游戏中的“大Bank”（如C0）的数据在加载后不会改变，因此可以利用其中所有12个ROM Bank中的大量空闲空间来存储额外文本 [00:38:55]

    

英文字体 [00:39:25]

• 包含细体和宽体数字、字母和标点 [00:39:36]
  • 视频展示了最终采用的英文字体，包括宽体区（绿色）和细体区（紫色），用于容纳大小写字母和标点符号 [00:39:36]

    

• 两套数字字符的原因 [00:39:46]
  • 游戏中需要两套数字字符，一套用于常规文本，另一套用于如战斗伤害数值的格式化输出 [00:39:50]
  • 可能会出现宽窄字体混用的情况，但对于这类游戏来说比较常见 [00:40:03]

    

最终翻译效果 [00:40:34]

• 实现变宽字体效果 [00:40:46]
  • 最终的文本显示效果超出了预期，成功实现了在Wonders Swan上的变宽字体效果 [00:40:34]
  • 这得益于游戏原始程序员出色的工作，他们为该系统实现了高级的渲染功能 [00:40:53]

    

翻译过程总结 [00:41:05]

• 1. 学习平台基础知识（寻址、指针、Bank等） [00:41:05]
• 2. 弄清文件存储、Bank划分 [00:41:08]
• 3. 匹配图块地图数据进行提取/插入 [00:41:11]
• 4. 识别文本格式 [00:41:13]
• 5. 在稳定的ROM区域寻找空闲空间并进行寻址 [00:41:16]
• 6. 构建文本插入工具 [00:41:18]
• 7. 修复英文特定代码错误 [00:41:21]