这个项目用 N64Recomp 工具链把 N64 游戏 Ogre Battle 64: Person of Lordly Caliber（美版 Rev A）静态重编译成原生 PC 可执行文件，仓库内不含任何受版权保护的游戏数据，需要玩家自行提供 ROM 转储。运行条件为 64 位 PC：GPU 在 Windows 上需支持 Direct3D 12.0（着色器模型 6.0）或 Vulkan 1.2，Linux 用 Vulkan 1.2，macOS 用 Metal，覆盖到的最老显卡约为 2012 年的 GeForce GT 630、Radeon HD 7750 和 Intel HD 510（Skylake）；CPU 需为支持 SSE4.1 的 x86-64，macOS 版本要求 Apple Silicon。
正文
Ogre Battle 64: Person of Lordly Caliber（PC 移植项目）
使用 N64Recomp 工具链，将 N64 游戏 Ogre Battle 64: Person of Lordly Caliber（美版，Rev A）静态重编译为原生 PC 可执行文件。本仓库不含受版权保护的游戏数据，你必须提供自己的 ROM dump（见下文）。
系统需求
需要 64 位 PC 及渲染器支持的 GPU： GPU — Windows 下需 Direct3D 12.0（Shader Model 6.0）或 Vulkan 1.2，Linux 下 Vulkan 1.2，macOS 下 Metal。覆盖的最老 GPU 大致为 GeForce GT 630、Radeon HD 7750（2012）和 Intel HD 510（Skylake）。 CPU — 支持 SSE4.1 的 x86-64（Intel Core 2 Penryn、AMD Bulldozer 或更新）。macOS 构建需要 Apple Silicon。 OS — Windows 10 或 11（64 位）；Apple Silicon 上的 macOS 11 或更新；带 Vulkan 1.2 驱动的 glibc Linux。 RAM — 2 GB，模拟的 N64 机器占用 512 MB。 磁盘 — 应用约 150 MB，外加 ROM。 游戏数据 — 你自己的 Ogre Battle 64（美版，Rev A）卡带 dump，40 MB，格式为 .z64、.n64 或 .v64。不含游戏数据。
键盘即可游玩；支持 XInput（Windows）或 SDL 的手柄可选。音频设备也可选，没有则静音运行。Windows 下不需要 Visual C++ 运行库——包里自带着色器编译器所需的运行环境。如果游戏启动时崩溃，先更新显卡驱动。在较老 GPU 上，OGRECONSOLE=1 会打开带启动日志的控制台，OGREGRAPHICS_API 可锁定后端（vulkan 或 d3d12）。
AI 声明
本项目的工作主要由 DeepSeek v4/v4.1 Flash 模型完成。
状态
完整计划、当前状态和技术发现见 PLAN.md。
目录结构
- assets/ 你的 ROM（git 忽略；预期为大端 .z64）
- asm/ splat 生成的反汇编
- debug/ wasm 构建的无头浏览器探针（见 debug/README.md）
- config.yaml splat 配置（段、vram 映射）
- config.toml N64Recomp 配置
- Makefile 组装 + 链接 + 重编译
- n64recomp-ob64.patch 我们的 N64Recomp 修改（应用到上游克隆）
- rt64-plume-sdl.patch 我们的 RT64 plume 补丁——SDL >= 2.0.22 保护（在 SDL2 较老的系统如 Ubuntu 22.04 上应用到 tools/RT64 子模块）
- PLAN.md 项目计划
开始使用
详见 PLAN.md 中的 Reproduce。简述：在 macOS 上用 brew 安装 mips-linux-gnu-binutils 和 cmake，用 python3 -m venv 建虚拟环境并 pip 安装 splat64[mips]；递归克隆 N64Recomp 至 tools/N64Recomp 并打补丁，用 cmake 配置构建 N64RecompCLI。将 .z64 dump 放入 assets/ 后运行 make regenerate 重新生成重编译代码。
ROM 必须是美版 Rev A dump（40 MB，.n64 为 16 位字节交换或已转换的 .z64）。tools/convertrom.py 可转 .n64 → .z64。刚克隆的仓库无法构建应用，直到运行过一次 make regenerate：重编译的 C 代码（RecompiledFuncs/、Bank*Funcs/、RspFuncs/、app/src/bankfuncs.inc）从你的 ROM 生成，故意不提交。make regenerate 按唯一可行的顺序运行 splat、MIPS 链接、34 个 bank 单元、主重编译和 RSP 微码。
构建并运行应用
用 cmake -S app -B build-app -DCMAKEBUILDTYPE=Release 配置，cmake --build build-app -j 构建，然后运行 ./build-app/ogrebattle64。启动时应用显示黑屏起始画面——“OGRE BATTLE 64: RECOMP / CLICK TO LOAD YOUR ROM (OR DROP IT IN THIS WINDOW)”。点击它选择 ROM，将 ROM 拖入窗口，或把 ROM 放在可执行文件旁。ROM 经哈希验证后存储，之后启动直接进入游戏。电池存档位于可执行文件旁的 saves/。
可玩构建
运行 make dist 生成 dist/ogre-battle-64-recomp/ 单一自包含可执行文件目录，make dist-zip 生成 dist/ogre-battle-64-recomp-
渲染器（tools/RT64）是固定到上游提交的 git 子模块，在 SDL < 2.0.22 的系统（如 Ubuntu 22.04 自带 SDL 2.0.20，但 SDL_GetWindowSizeInPixels 需要 2.0.22+）需一次性打补丁： - git submodule update --init --recursive - git -C tools/RT64/src/contrib/plume apply ../../../../rt64-plume-sdl.patch
tools/RT64 内任何 git submodule update 会重置子模块并丢弃补丁，需重新应用。
法律
Ogre Battle 64 © Quest / Nintendo。本项目用于保存和互操作性研究。切勿分发 ROM 或其提取的资源。
评论
讨论以怀旧和好奇为主基调，技术派关心重编译的原理与进度，老玩家则争论这款游戏是否被低估；最尖锐的分歧在于「由 AI 完成的重编译算不算数」，以及这类项目的法律地位是否比模拟器更暧昧。
认为 AI 参与的重编译根本不该用
- 有人直接点名该项目由 DeepSeek 生成，主张它算不上真正的重编译，并警告可能包含盗用或受版权保护的代码，号召大家别碰（少数人）
质疑这类项目的法律地位比模拟器更模糊
- 有人追问重编译项目的合法性究竟比模拟器更灰还是更不灰，而项目方给出的答案是必须自备 ROM，等于把版权风险留给用户（较多人）
认为这款游戏被严重低估，值得重玩
- 老玩家称它是 N64 上的顶尖作品之一，因为松野泰己没有参与，常被拿来和《皇家骑士团》《最终幻想战略版》比较时被忽视，但素质远超前作，也足以和松野最好的作品并肩（较多人） > 它比起初代《奥伽战争》高出一大截，完全能和松野的巅峰之作平起平坐。（@AdmiralAsshat）
怀疑它真有那么多死忠
- 有人查了当年的评测，觉得只是中上水平，问它是不是有某种 cult 追随者，或者出名另有原因；也有人只是感慨很多年没想起过这款游戏（少数人）
不理解重编译产物为何还要现代硬件
- 有人坦言完全不懂重编译的原理，但既然是从旧主机代码转译出来的，为什么跑起来还需要比原平台新二十年的机器（较多人）
想要聚合站点和同类项目教程
- 有人问有没有网站专门汇总这类重编译项目并追踪进度；另一人则希望找到针对老 DOS 游戏的重编译项目，特别是用 Borland Turbo C 写的那些，甚至只求教程（少数人）
有价值的补充
- 进度百分比是按「还需要重新编译的函数数量」估算的，目前已经可以游玩甚至制作 mod，但和其他重编译项目一样需要玩家自备 ROM（@frozenlettuce）
- 该作的结局由攻占要塞时选择「解放」还是「征服」决定，实质是比较角色与要塞的对齐值，游戏内完全没有解释；有人首次通关没看攻略、玩了 60 多小时仍拿到最差结局（@AdmiralAsshat）
- 有人把这件事类比成「刚调试完最后一个诡异边界情况」，赞叹这相当于把一整部 N64 游戏推进到接近完工（@Tbarlow）