突發(fā)slap——多功能ROM補(bǔ)丁工具登場ROM補(bǔ)丁工具可將補(bǔ)丁文件應(yīng)用到游戲文件上把原始文件轉(zhuǎn)換為變體如翻譯版、修復(fù)版或其他修改版本。通常分發(fā)游戲修改成果是制作并分發(fā)用于原始文件的補(bǔ)丁。工具簡介有開發(fā)者開發(fā)了一款名為slap的ROM補(bǔ)丁工具它免費(fèi)且開源FOSS、跨平臺(tái)、支持二十種格式、界面可愛、運(yùn)行速度快還能生成小體積的補(bǔ)丁。開發(fā)該工具是因?yàn)樵贚inux系統(tǒng)上找不到符合需求且能與為[FXPak]準(zhǔn)備補(bǔ)丁良好配合的CLI工具所以它部分是為方便腳本編寫設(shè)計(jì)同時(shí)具備詳細(xì)輸出信息能針對(duì)各種情況給出結(jié)構(gòu)化的錯(cuò)誤、警告和提示。該工具對(duì)補(bǔ)丁不做預(yù)設(shè)有信心處理所有“有效”的補(bǔ)丁若補(bǔ)丁格式有誤或操作結(jié)果意外slap會(huì)明確指出問題所在。slap的[CLI版本]和[Web版本]均可獲取它采用Haskell和Rust編寫能在瀏覽器中良好運(yùn)行。slap支持六種操作apply補(bǔ)丁 原始ROM → 修改后的ROMcreate兩個(gè)ROM → 補(bǔ)丁undo補(bǔ)丁 修改后的ROM → 原始ROMconvert一種格式的補(bǔ)丁 → 另一種格式的補(bǔ)丁explain補(bǔ)丁 → 人類可讀的操作說明info補(bǔ)丁 → 補(bǔ)丁元數(shù)據(jù)。附錄正確性對(duì)于任何“實(shí)際可能存在”的補(bǔ)丁“正確應(yīng)用”是基本要求但可接受的邊界需思考針對(duì)每種格式“特性X”的相關(guān)問題如特性X是否屬于“規(guī)范”范疇、是否由應(yīng)用者自行決定的特殊情況、是否是雖不在“規(guī)范”內(nèi)但具備的能力等。文中給出了一些具體例子如IPS補(bǔ)丁要考慮什么樣的IPS補(bǔ)丁才算格式良好、記錄能否重疊、能否非單調(diào)排列等問題且IPS無法處理超過16MiB的文件但能描述起始位置在16MiB內(nèi)但寫入范圍超出該界限的記錄這種情況是否符合“規(guī)范”也需探討EBP補(bǔ)丁支持JSON元數(shù)據(jù)要思考“規(guī)范”是“除字符串外存在其他內(nèi)容即為錯(cuò)誤”還是“任意無限嵌套”以及能否確定它必須是UTF - 8編碼NINJA2補(bǔ)丁有“正?；睓C(jī)制若輸入的ROM不在“標(biāo)準(zhǔn)形式”補(bǔ)丁工具應(yīng)轉(zhuǎn)換但若補(bǔ)丁要求應(yīng)用不了解的正常化程序工具會(huì)拒絕應(yīng)用同時(shí)該格式存儲(chǔ)輸入文件的校驗(yàn)和且基于輸入的“標(biāo)準(zhǔn)形式”開發(fā)者認(rèn)為這過于保守要思考工具能否實(shí)現(xiàn)檢查輸入文件是否已符合預(yù)期格式BPS補(bǔ)丁似乎允許“在輸出的某些部分還未填充內(nèi)容時(shí)從這些部分復(fù)制數(shù)據(jù)”這種操作是否合理也需考慮PPF3補(bǔ)丁不跟蹤文件大小且支持撤銷操作但描述文件大小變化會(huì)使撤銷操作不合理原始工具試圖阻止文件大小變化但可能無效若用戶創(chuàng)建改變文件大小且支持撤銷的PPF3補(bǔ)丁或想使用撤銷功能但因格式結(jié)構(gòu)無法檢測是否試圖截?cái)辔募撊绾翁幚硪彩菃栴}。在創(chuàng)建補(bǔ)丁時(shí)采取保守策略確保生成的補(bǔ)丁能被任何工具正常應(yīng)用在應(yīng)用補(bǔ)丁時(shí)嘗試支持每種格式的全部“表達(dá)范圍”需明確“界限”所在。開發(fā)者花費(fèi)大量時(shí)間思考補(bǔ)丁可能出現(xiàn)的問題如包含不合理指令還用于確保能準(zhǔn)確識(shí)別補(bǔ)丁的各種格式錯(cuò)誤。文本編碼問題部分格式可存儲(chǔ)文本元數(shù)據(jù)開發(fā)者原本以為部分甚至全部格式僅支持ASCII編碼實(shí)際并非如此。輸出UTF - 8編碼的數(shù)據(jù)并確信這樣做在所有情況下都“沒錯(cuò)”常見規(guī)則要么是“該格式使用UTF - 8編碼”要么是“該格式使用‘系統(tǒng)代碼頁’”在現(xiàn)代系統(tǒng)中UTF - 8就是系統(tǒng)代碼頁所以后者也允許使用UTF - 8編碼。在讀取和顯示方面更復(fù)雜提供了多種備用解碼選項(xiàng)以防UTF - 8不是讀取補(bǔ)丁的正確編碼方式。對(duì)解碼和讀取的數(shù)據(jù)進(jìn)行保護(hù)和清理有幾種格式的元數(shù)據(jù)字段可存儲(chǔ)“任意數(shù)據(jù)”通常用來存儲(chǔ)文本所以既不想將這些字段與常規(guī)的顯示和格式轉(zhuǎn)換保存機(jī)制隔離開也不想讀取并執(zhí)行可疑嵌入式文件中的大量控制字符做法是顯示所有內(nèi)容但不執(zhí)行任何操作不可打印的代碼點(diǎn)會(huì)以轉(zhuǎn)義形式顯示若所選編碼無法解碼字節(jié)序列則顯示為UFFFD并給出警告說明位置。性能測試需要說明的是CLI表格中的每個(gè)數(shù)據(jù)都包含進(jìn)程啟動(dòng)時(shí)間該工具也不例外最小的測試用時(shí)受10 - 25ms的執(zhí)行和運(yùn)行時(shí)間下限影響而非單純的補(bǔ)丁操作時(shí)間。選取了四組前后對(duì)比的文件4MiB的GBC ROM、16MiB的GBA ROM、64MiB的N64 ROM和520MiB的光盤鏡像。對(duì)于每種格式若有合適的參考工具可用于腳本化測試會(huì)讓每個(gè)工具從參考文件對(duì)中創(chuàng)建補(bǔ)丁并應(yīng)用記錄時(shí)間取多次運(yùn)行的中位數(shù)。在記錄時(shí)間前會(huì)逐字節(jié)檢查每個(gè)輸出是否與參考文件對(duì)一致。每個(gè)單元格的格式為“slap / 參考工具”運(yùn)行時(shí)間超過十五秒的記錄為“15s”空白單元格表示該大小下未進(jìn)行該組合的測試“—”表示測試運(yùn)行但無有效數(shù)據(jù)可測量ppf3的測試在雙方都關(guān)閉撤銷數(shù)據(jù)的模式下進(jìn)行這是參考工具的默認(rèn)模式。文中給出了創(chuàng)建補(bǔ)丁的時(shí)間、創(chuàng)建的補(bǔ)丁大小、應(yīng)用slap創(chuàng)建的補(bǔ)丁的時(shí)間等測試表格。在應(yīng)用補(bǔ)丁方面表現(xiàn)有勝有負(fù)在卡帶大小的文件上差距僅為幾十毫秒且每個(gè)應(yīng)用程序都能完美處理slap生成的補(bǔ)丁。還說明了javaxdelta在每次計(jì)時(shí)調(diào)用時(shí)都會(huì)啟動(dòng)一個(gè)JVM這一開銷在4MiB文件的測試中占主導(dǎo)地位但在520MiB文件的測試中可忽略不計(jì)其庫本身運(yùn)行速度較快applyppf3和ninja應(yīng)用程序會(huì)直接修改文件而不是生成新的輸出文件所以每次計(jì)時(shí)測試都會(huì)使用預(yù)先制作的副本且復(fù)制文件的時(shí)間不計(jì)入測試在520MiB文件的測試中slap的應(yīng)用時(shí)間主要用于寫入520MiB的輸出文件而直接修改文件的應(yīng)用程序只需寫入更改的字節(jié)這一行的數(shù)據(jù)實(shí)際上是兩種不同操作的對(duì)比。瀏覽器環(huán)境測試Web版slap通常與社區(qū)長期使用的標(biāo)準(zhǔn)工具[RomPatcher.js]進(jìn)行比較。選取了三組適合瀏覽器測試的文件對(duì)4MiB和64MiB ROM以及一組8MiB的文件對(duì)適用于無法處理64MiB文件的ips和ebp格式。雙方都應(yīng)用slap生成的補(bǔ)丁空白單元格表示該大小下未進(jìn)行該組合的測試。雙方的測試都在預(yù)熱狀態(tài)下進(jìn)行即啟動(dòng)一次文件已加載到內(nèi)存中與CLI表格不同這些測試數(shù)據(jù)不包含啟動(dòng)時(shí)間。文中給出了創(chuàng)建補(bǔ)丁的時(shí)間、創(chuàng)建的補(bǔ)丁大小、應(yīng)用補(bǔ)丁的時(shí)間等測試表格。在4MiB文件的測試中RomPatcher.js在純JavaScript環(huán)境下執(zhí)行與我們的Rust差異算法相同的搜索操作導(dǎo)致運(yùn)行時(shí)間長達(dá)15s但其生成的補(bǔ)丁大小與我們的相近。超過4MiB后這是其源代碼中的一個(gè)閾值它會(huì)切換到線性遍歷算法速度明顯加快但生成的補(bǔ)丁更大這一權(quán)衡在補(bǔ)丁大小表格中有所體現(xiàn)。完整的測試數(shù)據(jù)、測試框架以及六種沒有可腳本化參考工具進(jìn)行對(duì)比的CLI格式的測試結(jié)果都可以在[結(jié)果目錄]中找到。