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 。
