ReC98
versary Edition)
| 反向工程： | |
|---|---|
| 最終確定： | |
| 位置獨立性： |
檢查主頁以獲取有關眾籌的更詳細的進度數字和信息！
該項目旨在完美地重建Zun Soft （現為上海愛麗絲隊）的前五個Touhou Project Games的源代碼，該項目最初是專門針對NEC PC-9801系統發布的。
有關的原始遊戲是：
由於我們只有二進製文件，因此我們顯然不知道Zun如何命名任何變量和功能，以及原始代碼被包圍的哪些評論。因此，完美意味著從REC98存儲庫中編制的代碼編譯的二進製文件與Zun的原始版本沒有區別，因此不可能反駁原始代碼看起來不像這樣。此屬性沿此過程中的每個git犯罪都維護。
除了保存角度以及對遊戲機制的深入了解之外，該代碼還可以作為由社區開發的任何類型的MOD或任何類型的MOD或任何非PC-98平台的端口的基礎。這也是為什麼REC98值在純粹的解說上值可讀和可理解的代碼。
與Pytouhou-style Black-Box重新實現相比，PC-98遊戲通過完整的不合同性實現可調節性似乎更值得：有幾種原因：
自從眾籌帶來不斷的支持以來，進步一直穩定。 TH01的解碼在2022年8月完全完成，其餘遊戲只是時間問題。
多年來，該項目使對原始編譯器和PC-98硬件有深刻的了解，以至於解碼本身已經變得非常機械。為了確保該項目既值得支持，又值得開展工作，它的重點更多地轉移到了精心的文檔和對Zun原始代碼的審查中。該項目博客以更普遍可讀性的方式詳細介紹了所有發現，並且可以說是主要的吸引力，源代碼重建本身幾乎變成了對這些遊戲的深入研究的副產品。
該項目也很可行。在開發這些遊戲的靜態英語補丁過程中，我們確定了所有5場遊戲中使用的兩個主要庫，甚至找到了它們的源代碼。這些都是：
ZUNSP.COM （可通過ZUN.COM -4訪問）是Promisisence Soft的SPRITE16.COM的重新品牌版本，這是一個16顏色的PC-98 EGC顯示器，版本0.04，與示例遊戲stormysmyspace捆綁在一起。 Master.lib和C/C ++運行時單獨構成了所有可執行文件中的大量代碼。例如，在TH05中，它們佔OP.EXE中所有代碼的74％，而MAIN.EXE中的所有代碼的40％。這已經是我們不必處理的很多代碼。確定整個遊戲中共享的代碼的其餘部分將進一步將工作量減少到更可接受的數量。
借助Dosbox-X和Neko Project II的Debug Edition，我們還擁有兩個開源PC-9821模擬器，能夠運行遊戲。這些幫助回答了與硬件相關的大多數問題，以及有關PC-98開發以及偶爾對真實硬件的測試的舊書籍。
zunsoft.com ， op.exe ， reiiden.exe ， fuuin.exeongchk.comzuninit.com ， zun_res.com ， zunsoft.comop.exe ， main.exe ， maine.exeongchk.comzuninit.comzunsoft.comzunsp.com [-4]， res_yume.com [-5]）， op.exe ， main.exe ， mainl.exeongchk.comzuninit.com [-i]， res_huma.com [-s]， memchk.com [-m]）， op.exe ， main.exe ， maine.exeongchk.comzuninit.com [-i]， res_kso.com [-s]， gjinit.com [-g]， memchk.com [-m]）， op.exe ， main.exe ， maine.exe交叉文件與上一款遊戲中的版本相同。 Ongchk.com是Kaja的PMD聲音驅動程序的一部分，因此也不需要拆卸。我們只需要保留二進製文件即可允許Zun.com的有點完美的重建。
該項目不包括原始PC-98版本中的任何資產數據。運行編譯的可執行文件仍然需要原始遊戲的現有副本。
▶ master ：Zun的原始代碼，沒有mod或bugfix （您在這裡！）
debloated ：Zun代碼的重新搜索版本，易於讀取和修改，並構建較小，更快的PC-98二進製文件。僅清除膨脹和地雷； Zun原始代碼中的所有錯誤和怪癖都留在位。端口應從該分支開始，也是不在乎與原始二進制的相似性的mod的推薦基礎。
anniversary ：進行debloated並另外修復了錯誤，在PC-98平台上實現了更流暢且無閃爍的遊戲體驗，同時仍將怪癖留在原地。對於mod和端口，可能是更好的啟動端口。
BossRush
th03_no_gdc_frequency_check ：允許將TH03設置為5 MHz。原始遊戲強制執行2.5 MHz，但在實際硬件上也不需要功能。
xJeePx ：Xjeepx 2014年英語翻譯補丁的代碼更改。
th01_critical_fixes ：修復了TH01中的兩個關鍵錯誤：
th01_end_pic_optimize ：將TH01過場動畫中的圖像閃爍加快到原始運行時的50％。主要是如何在不編寫單個ASM指令的情況下與Turbo C ++ 4.0J的最佳EGC驅動的打擊代碼接近的示例； EGC絕對不是這項工作的最佳工具。
th01_orb_debug ：以TH01的調試模式顯示以下信息：
th01_sariel_fixes ：在TH01 Sariel戰鬥中修復了三個精靈故障，這是由於原始代碼中的清晰邏輯錯誤而導致的。
th03_real_hitbox ：將TH03的碰撞位圖渲染到兩個遊戲場上。高度無法播放。
修復TH04階段5 Yuuka no-Ems崩潰的修復：
th04_noems_crash_fix ：將TH04 MAIN.EXE的自我內存限制提高到修復該崩潰的適當量。mem_assign_all ：刪除所有TH02-TH05可執行文件中自我施加的內存限制，此外，還可以修復修改過程中可能發生的其他潛在的內存崩潰。TH04 kurumi劃分錯誤崩潰的解決方法：
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverTH04階段4 Marisa Divide錯誤崩潰的解決方法：
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes ：所有“明顯”錯誤的組合分支不影響遊戲玩法或視覺效果：
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fix再加上TH04的Divide Error錯誤的以下解決方法，由社區投票選擇：
th04_0_ring_as_single_bullet （民意調查結果）th04_marisa4_crash_still （投票結果） Borland Turbo C ++ 4.0J
這是ZUN最初使用的編譯器，因此它是唯一可以確定將此代碼編譯到可執行文件的ZUN的編譯器，該代碼符合Zun的原始版本。 Borland從未在32位窗戶上進行16位DOS的跨編譯器，因此必須使用16位DOS程序來編譯C ++零件。
REC98還使用Turbo C ++ 4.0J在其構建管道中構建自定義工具，例如用於硬編碼Sprites的轉換器。這些只需作為構建過程的一部分而本地運行，因此將它們編譯成16位DOS程序可能會適得其反，然後需要在64位操作系統上模擬這些程序。但是，這仍然是有意義的，原因有幾個：
因此，將通常非常重的依賴性添加到本機C ++編譯器上幾乎沒有意義。
Borland Turbo Assembler（TASM），版本5.0或更高版本，用於32位窗戶（ TASM32.EXE ）
REC98不僅需要一個尚未分解的遊戲代碼的彙編器，而且還需要PC-98 Touhou的第三方庫以及Zun自己的手寫和不可兼容的裝配代碼。值得慶幸的是，Borland的32位彙編程序可用於16位代碼，並在64位和32位窗口上本地運行，表現優於16位TASM.EXE和TASMX.EXE工具。
作為附帶好處，使用本機32位Windows工具還允許ASM零件自由使用不需要符合DOS 8.3約定的長文件名。
MS-DOS播放器（捆綁）
輕巧的模擬器，用於在Windows控制台子系統上運行DOS命令行工具，在64位操作系統上構建代碼庫時會自動使用。儘管其脫落的性質，它仍然比DOSBox慢得多，因為它使用Neko Project 21/W的解釋X86 Core而不是動態的重新編譯器，但無縫的控制台集成卻遠遠超過了。
捆綁的構建專門針對建築Rec98進行了精選，運行了一個減少的X86核心，該核心僅模擬沒有FPU，分頁或週期計數的386。與Takeda Toshiya的上游構建相比，對於完整的重建，此構建的構建速度約為60％，約80％，用於編譯和鏈接最大的翻譯單元和最大的二進制單元，中間尺寸的翻譯單元和binarial和binary約為70％。它還包含在截至2024年6月上游構建中無法使用的構建系統中，在構建系統中運行Turbo C ++ 4.0J所需的錯誤即可。
有關許可並構建信息，請參見bin/README.md 。
tup ，用於窗戶（捆綁）
一種理智的平行構建系統，用於確保最少的重建。通過代碼注入和掛接編譯器的文件打開syscalls，提供依賴項的完美跟踪，從而使其能夠自動將所有#include D文件添加到構建依賴關係圖中。這使其優於大多數make實現，這些實現缺乏這一重要功能，因此本質上不適合任何可以想像的編程語言。由於沒有針對特定編譯器的抽象，TUP也與該項目所需的古老的Borland工具完全吻合。
捆綁的64位Windows Build包括一個重要的錯誤編號，用於通過MS-DOS播放器運行基於DOS的構建工具，該工具截至2024年6月截至上游存儲庫尚未合併到上游存儲庫中。
有關許可並構建信息，請參見bin/README.md 。
只需在任何受支持的構建平台上運行build.bat即可；無論您運行哪種操作系統，它都會做正確的事情。如果在Windows PATH中找不到任何必要的工具，則該過程將流產出錯誤。
最終的可執行文件將放入binth0? ，使用與原件相同的名稱。運行它們需要在同一目錄中每個遊戲的原始資產。
在64位X86上，構建過程使用TUP進行最小的並行重建，但所有基於DOS的構建工具都會模仿。在32位x86上，構建過程落在始終構建整個代碼庫的順序批處理文件上，但是所有構建工具都可以按本機性能運行。
第1層：定期測試，保證最佳支持。
第2層：應該工作，可行，但不能定期測試。構建過程中的關鍵錯誤將免費修復。
第3層：應該工作，但要維持負擔。與構建相關的錯誤的修復程序將需要資金，但是BugFix PR也可能被接受。
第4層：明確沒有規定和不可行的情況，沒有嚴重修補。將需要專門的資金或叉子，PR不太可能被接受。
TLINK失敗Loader error (0000): Unrecognized Error
兩個已知原因：
嘗試通過編輯%WINDIR%System32autoexec.nt ：配置將NTVDM DPMI驅動程序加載到常規內存中而不是上內存中：
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosx在該編輯之後需要重新啟動才能生效。
（來源）
嘗試在常規的cmd.exe外殼中而不是powershell或bash中構建。
參見CONTRIBUTING.md 。
