slap：免费开源跨平台的ROM补丁工具，支持六种操作且性能测试表现出色！

突发slap——多功能ROM补丁工具登场ROM补丁工具可将补丁文件应用到游戏文件上把原始文件转换为变体如翻译版、修复版或其他修改版本。通常分发游戏修改成果是制作并分发用于原始文件的补丁。工具简介有开发者开发了一款名为slap的ROM补丁工具它免费且开源FOSS、跨平台、支持二十种格式、界面可爱、运行速度快还能生成小体积的补丁。开发该工具是因为在Linux系统上找不到符合需求且能与为[FXPak]准备补丁良好配合的CLI工具所以它部分是为方便脚本编写设计同时具备详细输出信息能针对各种情况给出结构化的错误、警告和提示。该工具对补丁不做预设有信心处理所有“有效”的补丁若补丁格式有误或操作结果意外slap会明确指出问题所在。slap的[CLI版本]和[Web版本]均可获取它采用Haskell和Rust编写能在浏览器中良好运行。slap支持六种操作apply补丁 原始ROM → 修改后的ROMcreate两个ROM → 补丁undo补丁 修改后的ROM → 原始ROMconvert一种格式的补丁 → 另一种格式的补丁explain补丁 → 人类可读的操作说明info补丁 → 补丁元数据。附录正确性对于任何“实际可能存在”的补丁“正确应用”是基本要求但可接受的边界需思考针对每种格式“特性X”的相关问题如特性X是否属于“规范”范畴、是否由应用者自行决定的特殊情况、是否是虽不在“规范”内但具备的能力等。文中给出了一些具体例子如IPS补丁要考虑什么样的IPS补丁才算格式良好、记录能否重叠、能否非单调排列等问题且IPS无法处理超过16MiB的文件但能描述起始位置在16MiB内但写入范围超出该界限的记录这种情况是否符合“规范”也需探讨EBP补丁支持JSON元数据要思考“规范”是“除字符串外存在其他内容即为错误”还是“任意无限嵌套”以及能否确定它必须是UTF - 8编码NINJA2补丁有“正常化”机制若输入的ROM不在“标准形式”补丁工具应转换但若补丁要求应用不了解的正常化程序工具会拒绝应用同时该格式存储输入文件的校验和且基于输入的“标准形式”开发者认为这过于保守要思考工具能否实现检查输入文件是否已符合预期格式BPS补丁似乎允许“在输出的某些部分还未填充内容时从这些部分复制数据”这种操作是否合理也需考虑PPF3补丁不跟踪文件大小且支持撤销操作但描述文件大小变化会使撤销操作不合理原始工具试图阻止文件大小变化但可能无效若用户创建改变文件大小且支持撤销的PPF3补丁或想使用撤销功能但因格式结构无法检测是否试图截断文件该如何处理也是问题。在创建补丁时采取保守策略确保生成的补丁能被任何工具正常应用在应用补丁时尝试支持每种格式的全部“表达范围”需明确“界限”所在。开发者花费大量时间思考补丁可能出现的问题如包含不合理指令还用于确保能准确识别补丁的各种格式错误。文本编码问题部分格式可存储文本元数据开发者原本以为部分甚至全部格式仅支持ASCII编码实际并非如此。输出UTF - 8编码的数据并确信这样做在所有情况下都“没错”常见规则要么是“该格式使用UTF - 8编码”要么是“该格式使用‘系统代码页’”在现代系统中UTF - 8就是系统代码页所以后者也允许使用UTF - 8编码。在读取和显示方面更复杂提供了多种备用解码选项以防UTF - 8不是读取补丁的正确编码方式。对解码和读取的数据进行保护和清理有几种格式的元数据字段可存储“任意数据”通常用来存储文本所以既不想将这些字段与常规的显示和格式转换保存机制隔离开也不想读取并执行可疑嵌入式文件中的大量控制字符做法是显示所有内容但不执行任何操作不可打印的代码点会以转义形式显示若所选编码无法解码字节序列则显示为UFFFD并给出警告说明位置。性能测试需要说明的是CLI表格中的每个数据都包含进程启动时间该工具也不例外最小的测试用时受10 - 25ms的执行和运行时间下限影响而非单纯的补丁操作时间。选取了四组前后对比的文件4MiB的GBC ROM、16MiB的GBA ROM、64MiB的N64 ROM和520MiB的光盘镜像。对于每种格式若有合适的参考工具可用于脚本化测试会让每个工具从参考文件对中创建补丁并应用记录时间取多次运行的中位数。在记录时间前会逐字节检查每个输出是否与参考文件对一致。每个单元格的格式为“slap / 参考工具”运行时间超过十五秒的记录为“15s”空白单元格表示该大小下未进行该组合的测试“—”表示测试运行但无有效数据可测量ppf3的测试在双方都关闭撤销数据的模式下进行这是参考工具的默认模式。文中给出了创建补丁的时间、创建的补丁大小、应用slap创建的补丁的时间等测试表格。在应用补丁方面表现有胜有负在卡带大小的文件上差距仅为几十毫秒且每个应用程序都能完美处理slap生成的补丁。还说明了javaxdelta在每次计时调用时都会启动一个JVM这一开销在4MiB文件的测试中占主导地位但在520MiB文件的测试中可忽略不计其库本身运行速度较快applyppf3和ninja应用程序会直接修改文件而不是生成新的输出文件所以每次计时测试都会使用预先制作的副本且复制文件的时间不计入测试在520MiB文件的测试中slap的应用时间主要用于写入520MiB的输出文件而直接修改文件的应用程序只需写入更改的字节这一行的数据实际上是两种不同操作的对比。浏览器环境测试Web版slap通常与社区长期使用的标准工具[RomPatcher.js]进行比较。选取了三组适合浏览器测试的文件对4MiB和64MiB ROM以及一组8MiB的文件对适用于无法处理64MiB文件的ips和ebp格式。双方都应用slap生成的补丁空白单元格表示该大小下未进行该组合的测试。双方的测试都在预热状态下进行即启动一次文件已加载到内存中与CLI表格不同这些测试数据不包含启动时间。文中给出了创建补丁的时间、创建的补丁大小、应用补丁的时间等测试表格。在4MiB文件的测试中RomPatcher.js在纯JavaScript环境下执行与我们的Rust差异算法相同的搜索操作导致运行时间长达15s但其生成的补丁大小与我们的相近。超过4MiB后这是其源代码中的一个阈值它会切换到线性遍历算法速度明显加快但生成的补丁更大这一权衡在补丁大小表格中有所体现。完整的测试数据、测试框架以及六种没有可脚本化参考工具进行对比的CLI格式的测试结果都可以在[结果目录]中找到。