企业官网建设流程全解析

WiiCompiled 是一个把《马力欧卡丁车 Wii》搬上 PC 的开源项目，它不用模拟器、不用解释器、也不用 JIT，而是靠静态重编译把整盘游戏的 PowerPC 指令提前翻译成原生代码。它最硬核的卖点是：物理与真机100% 一致，而证明这件事的关键证据，正是游戏里的「幽灵数据」（Ghost）。本文带你搞懂：为什么幽灵回放能当"物理校验器"，静态重编译又凭什么做到逐位无误差。🎯

先搞懂：静态重编译和模拟器差在哪？

同样是"在 PC 上玩 Wii 游戏"，三种路线的本质区别如下：

一句话：按下 Play 的那一刻，你的电脑上没有任何东西在"扮演" Wii CPU，跑的就是纯原生代码（见 README.md）。

整个翻译管线记录在 translator/README.md 中：解析 GameCube/Wii 的 DOL 文件 → 解码 PowerPC 指令 → 经IR/SSA 提升和类型推断 → 输出 C++，最后和runtime/一起编译为原生可执行文件。项目自身的地址与路径由带版本的 YAML 清单注入，翻译器本体不含任何游戏数据（projects/mkwii/recomp.yml）。

幽灵数据揭秘：Ghost 为什么能当物理校验器？

项目官方 FAQ 对物理精度的回答只有一句话，信息量却极大：

"100% - this is proven by in-game ghosts. Since ghosts are replay files based on inputs rather than tracked positions, matching ghosts prove the physics match across Dolphin/Wii/Wiicompiled."

—— 摘自 README.md

翻译成大白话：

• MKW 的幽灵不是"位置录像"。它不记录"第 37 帧车在哪个坐标"，而是记录输入序列——每一帧按了哪些键、何时漂移、何时加速。
• 回放幽灵时，游戏引擎会用这套输入重新跑一遍物理模拟，实时算出每辆车的位置。
• 如果你录在真机上的幽灵，在 WiiCompiled 里能被自己的车贴身跟住、分毫不差，那就意味着：几分钟比赛、几万个物理帧、每帧成百上千次浮点运算，PC 上每一步的结果都与真机逐位相同。✅

反过来想就知道这份证据有多强：只要某一次浮点加减差了一个二进制位，误差就会像滚雪球一样在后续数万帧里不断放大，幽灵早就肉眼可见地飘走了。幽灵能稳定贴合，本身就是"零误差"最直观的实测。🔍

原理一：逐条指令复刻，浮点运算从不近似

无误差的第一块基石，是翻译器对指令语义的逐条忠实。

PowerPC 的每条指令先被解码，再"提升"（Lift）为中间表示（IR）节点。以浮点运算为例，PpcLifter.Floating.cs 中的映射非常直白：

• fadd（双精度加）→ IR 的精确add节点
• fadds（单精度加）→ 调用专门的PPC_Fadds语义实现

这里的难点在于Gekko/Broadway 的浮点单元（FPU）并不遵循标准 IEEE 754：它有独特的非规格化数冲刷（NI flush）规则，fres/frsqrte用的还是专用近似表而非通用算法。WiiCompiled 在 ppc_isa_float.h 中把这些"怪癖"原样移植了过来，连同 PpcFloatCallSemantics.cs 对成对单精度（paired-single）寄存器域的精确约束。

换句话说：不是"算出一个差不多的数"，而是复刻同一套运算规则，让 PC 上的每一次浮点结果与真机逐位一致。⚙️

原理二：时间基线精确锁定，物理节拍完全确定

物理模拟的确定性离不开确定性时钟。

真实 Wii 的总线时钟是 243 MHz，而游戏逻辑使用的 timebase 恰好是它的四分之一：

243,000,000 Hz ÷ 4 = 60,750,000 Hz（60.75 MHz）

WiiCompiled 在 timebase_contract.h 中把这一比例用编译期常量硬编码，并用static_assert保证换算关系在编译期就被验证。原盘游戏被硬性锁定在 60 fps，每一帧的物理步进消耗的 tick 数在真机、Dolphin 和 WiiCompiled 上完全相同——不存在"这帧多算了几个时钟周期"的模糊地带。⏱️

原理三：一次编译永久固定，不支持就不出货

与 JIT"边跑边改"不同，静态重编译产出的是一份固定不变的原生二进制：同一份程序、同一份输入，在任何机器上、任何时刻，输出都完全一致。

更关键的是项目的"洁癖"策略：

• 清单里allow_unsupported_instructions默认为false（projects/mkwii/recomp.yml）。
• 翻译器遇到无法精确翻译的指令时直接让构建失败，而不是偷偷近似（translator/README.md）。
• 运行时错误也刻意"大声报错"而非静默吞掉，官方明确以"行为与真机完全一致"为目标（README.md）。

宁可构建失败，也不发出一行不确定的代码——这正是"无误差"的底气所在。🛡️

完整流程一览：从 DOL 到原生可执行文件

静态重编译一共是四步（translator/README.md）：

1. translate-recursive：从入口点递归遍历调用图，解码所有可达函数，输出 C++ 及 JSON 元数据。
2. generate-data-init：生成.data/.rodata/.sdata数据段初始化和RuntimeConfig.h。
3. emit-build-shards：输出 CMake 构建图，覆盖生成源码与runtime/src。
4. CMake + Ninja + Clang把runtime/与生成代码编译为一个原生可执行文件。

为了保证"翻译对象就是官方原版"，清单还会用 SHA-256 钉死 DOL/REL 的哈希值（projects/mkwii/recomp.yml），任何改版、其他地区的镜像都会被直接拒绝。

新手常见疑问 FAQ

Q：它算模拟器吗？不算。所有代码在按下 Play 之前就已编译为原生代码，运行时没有任何 Wii CPU/GPU 模拟（README.md）。

Q：为什么安装要花这么久？因为项目不发布翻译好的二进制，安装时要在你的机器上把静态重编译器跑完整盘游戏，再用 C++ 编译器编译产物。这是一次性成本（README.md）。

Q：幽灵验证能证明什么程度的一致？官方结论是物理与 Wii / Dolphin 100% 匹配；至于渲染、联网和性能仍在持续完善中（README.md）。

Q：其他 GC/Wii 游戏也能这么编译吗？翻译器本身是通用的（示例清单见 projects/examples/generic-dol.yml），但一款"可玩"的移植还需要对应的运行时支持：音频、输入、GX 图形等，游戏碰到的每一个系统都得有人实现。

写在最后

「幽灵数据」之于 WiiCompiled，就像指纹之于双胞胎——输入驱动的回放机制，让 Ghost 成为一把天然的物理标尺。而 WiiCompiled 能稳稳"贴住"这把标尺，靠的是逐条指令的精确语义复刻、编译期锁定的时间基线、以及"不精确就拒绝出货"的静态编译哲学。这三者叠加，才换来那句最简洁的官方承诺：物理，100% 一致。🏁