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