突破 iOS 无 JIT 枷锁：d2r-mobile 的 AArch64 静态重写、NVN-Metal 转译与触控重构实践

在移动设备上运行主机级游戏向来面临一道难以逾越的技术鸿沟。苹果生态对 iOS / iPadOS 施加了严苛的安全沙盒机制与代码签名限制，其强制推行的 W^X（Write XOR Execute）安全策略彻底封禁了普通应用在运行时执行动态即时编译（JIT）或分配可执行内存的权限。这意味着传统的动态重编译模拟器在非越狱设备上寸步难行，往往只能依赖极其缓慢的纯解释器，或者在没有调试器附加时直接闪退。

然而，任天堂 Switch 掌机搭载的 Tegra X1 芯片采用标准的 64 位 ARMv8 架构，与 iPhone 和 iPad 所采用的 Apple Silicon 芯片在底层指令集架构上完全同构。近日开源的项目 d2r-mobile （GitHub 开源仓库：jhaizhou-ops/d2r-mobile），正是抓住了这一底层同构性，开创性地为《暗黑破坏神 II：狱火重生》（Diablo II: Resurrected，含术士君临扩展包）构建了一套兼具高性能与高稳定性的原生 iOS 兼容层。它完全不依赖 JIT 或动态转译，而是通过 AOT 静态二进制重写、高层操作系统服务接管（HLE）、NVN 到 Metal 离线着色器转译与 TBDR 能耗优化，以及深度的原生触控交互重构，实现了在 iOS 上 60 FPS 满帧直跑且整机功耗仅约 3.8W 的惊人表现。

1. 架构总览：从主机镜像到原生 iOS Mach-O 的技术拓扑

与传统模拟器在运行时维护庞大虚拟 CPU 状态机的方案不同，d2r-mobile 采用的是 “离线静态修补（AOT Rewriting） + 宿主高层服务接管（HLE） + 纯原生编译链接” 的工程路线。它将玩家自行提供的正版 Switch 游戏二进制文件解构，剥离所有 Horizon OS 特有依赖，并通过自定义的工具链将其打包装配为标准的 iOS 应用。

整个兼容层的体系结构可以清晰地划分为静态构建期流水线与运行时宿主层：

flowchart TD
    subgraph OfflinePipeline ["离线构建流水线 (Offline Pipeline)"]
        A["正版 Switch 镜像 (NSO 模块)"] --> B["patch_nso.py (AOT 静态指令重写)"]
        B --> C["gen_embed.py (嵌入式汇编生成)"]
        D["NVN Maxwell 着色器二进制"] --> E["dmsh_build.py (Ryujinx MSL 转译)"]
        E --> F["Metal Shader Library (.metallib)"]
        G["游戏原始资源 (RomFS/CASC)"] --> H["gen_assets.py (触控图集与宽屏遮罩)"]
    end

    subgraph HostRuntime ["运行时宿主环境 (Host Runtime / dmhost)"]
        C --> I["loader.c (内存映射与段权限初始化)"]
        I --> J["entry.S (dm_gate 只读密钥页蹦床)"]
        J --> K["hle.c / svc_dispatch (Horizon 系统调用接管)"]
        K --> L["Darwin 内核 / POSIX 线程与虚拟内存"]
        
        M["游戏原生图形调用 (NVN API)"] --> N["hle_nvn.c (nvnBootstrapLoader 拦截)"]
        N --> O["nvn_mtl.m (Metal 录制与 TBDR 通道重排)"]
        F --> O
        O --> P["Apple Silicon GPU 硬件渲染"]
        
        Q["多点触控与手势引擎 (front_ios.m)"] --> R["dm_actions.c (射线寻路 / 自动施法)"]
        R --> J
    end

从上述拓扑可以看出，游戏的 AArch64 机器码在 iPhone 的 CPU 上是以真实原生状态执行的，没有任何中间指令虚拟化翻译层。每一条浮点、整型和逻辑计算指令都由 Apple Silicon 的物理核心全速跑通，这也是该项目能够实现“冷启动 0.15 秒、切幕耗时仅 0.1 秒”的根本原因。

2. 突破 W^X 封锁：AArch64 静态二进制重写与 Keypage 蹦床门设计

在 iOS 系统中，App 启动后其代码段在内核层面被严格标记为不可写，而数据段则被标记为不可执行。如果像普通模拟器那样在运行时扫描指令并写入补丁，会立即触发 Darwin 内核的 EXC_BAD_ACCESS 保护性崩溃。d2r-mobile 必须在构建期完成全部修补，并确保修补后的代码能够被 Xcode 的代码签名体系合法签署。

2.1 指令级置换与静态剪口规则

Switch 游戏二进制由主程序 main、系统运行时 sdk 和辅助库 subsdk0 构成。虽然都是 AArch64 指令，但 Horizon 操作系统与 Apple Darwin 存在以下三个致命冲突：

系统调用指令：Horizon 使用 svc 指令陷入内核服务，而 iOS 拥有完全不同的系统调用号与内核 ABI；
系统计时器寄存器：游戏频繁读取系统计数器 cntpct_el0，Switch 硬件计数器固定为 19.2 MHz，而 Apple Silicon 芯片的计数器频率是 24 MHz；
平台保留寄存器：在 Apple 的 Darwin ARM64 ABI 中，寄存器 x18 被操作系统内核严格保留用作平台线程数据区（Platform Register），应用程序如果随意覆写 x18，会导致系统级崩溃；而在 Horizon 中，x18 只是普通通用寄存器。

为了解决这些冲突，重写工具 patch_nso.py 在离线阶段遍历反汇编机器码，执行严密的指令级修补：

sequenceDiagram
    autonumber
    actor Game as 游戏原生代码指令
    participant Gate as entry.S (dm_gate 蹦床)
    participant KeyPage as 只读密钥页 (Key Page)
    participant HLE as hle.c (gate_dispatch)
    participant Darwin as Darwin 系统 API / 线程槽

    Game->>Gate: 跳转至 gate 桩点
    Note over Gate: 保存调用上下文与全部通用寄存器
    Gate->>KeyPage: 间接读取只读密钥寻址
    KeyPage->>Darwin: 从线程槽位获取当前线程上下文
    Gate->>HLE: 携带原指令偏移进入 gate_dispatch
    HLE->>Darwin: 分发至 hle_svc / 计时器转译 (19.2MHz 虚拟基准)
    Darwin-->>HLE: 返回处理结果
    HLE-->>Gate: 恢复上下文与结果寄存器
    Gate-->>Game: 返回原程序下一条指令

所有危险指令均被替换为指向 dm_gate 的长跳转。为了防止运行时修改跳转地址，d2r-mobile 创新性地设计了 只读密钥页（Key Page） 机制：

内存加载器在程序映射区尾部预留一个只读页面；
线程槽位编号与入口点地址全部静态预计算并写入该页；
运行期间，每个线程通过间接寻址读取当前线程对应的上下文指针，保证代码段在加载完毕后能够直接施加 PROT_READ | PROT_EXEC 权限，之后永久不再变更，完全符合 iOS 的签名安全规范。

2.2 严格无副作用的“形式化剪口证明”

在逆向修改原版游戏逻辑时，最容易引入难以排查的竞态条件与空指针崩溃。d2r-mobile 团队制定了一套严密的 剪口（Cuts）规范：凡是被裁剪或修改的代码段，必须形式化证明其对外副作用、同步原语与锁依赖完全为空。

例如，在手机端上，游戏不再需要切换回 20 年前经典的像素低模画质，以大幅精简内存占用并消除多余的资源装载逻辑。工具链中对经典画面切换函数 0xb15d60 的修补如下：

# 经典画面切换写起点 / 目标（stp s2, s0, [x8, #4]）-> nop：目标恒为 1.0（新画面）
(0xb15e20, '0281002d', '1f2003d5', '经典画面切换写起点 / 目标 -> nop：目标恒为 1.0'),
# 经典画面切换清进度（str wzr, [x8, #0xc]）-> nop
(0xb15e24, '1f0d00b9', '1f2003d5', '经典画面切换清进度 -> nop')

项目不仅进行了简单的 nop 替换，还在注释和测试套件中给出了完整证明链条：

“过渡状态仅在 0x852280、0x85cb20、0x856be0 与 0xb15d60 四处写入。0xb15d60 是全程序唯一能将目标过渡进度推向 0.0 的地方。剪掉的两条存储指令不含函数调用、不含原子变量同步，且外部观察者探针命中为 0，因此全生命周期安全。”

3. 高层服务替换（HLE）与虚拟内存桥接

当底层指令能够在物理 CPU 上安全执行后，接下来的挑战是游戏对 Switch 操作系统内部服务的深度依赖。d2r-mobile 没有去模拟微内核（Microkernel）的 IPC 消息总线，而是采用高层仿真（HLE），在 SDK 接口层直接全面拦截。

3.1 虚拟地址空间拓扑与线程映射

Switch 的 Horizon OS 假设自身拥有独立的 39 位或 48 位平坦虚拟地址空间。在 iOS 上，hle_svc.c 借助 Darwin 的虚拟内存接口实现了内存桥接：

// 内存拓扑初始化关键逻辑抽象
void host_memory_init(void) {
    // 预留连续的大块虚拟内存区间，作为客户机堆空间与代码段基地址
    void *guest_base = mmap(NULL, GUEST_SPACE_SIZE, 
                            PROT_NONE, MAP_PRIVATE | MAP_ANON, -1, 0);
    // 按 Horizon 规范映射堆段 (Heap) 与代码段 (Text)
    mprotect(guest_base + CODE_OFFSET, CODE_SIZE, PROT_READ | PROT_EXEC);
    mprotect(guest_base + HEAP_OFFSET, INITIAL_HEAP_SIZE, PROT_READ | PROT_WRITE);
}

每个 Switch 内部创建的游戏线程，在宿主端都被直接映射为一个标准 POSIX 线程（pthread）。当游戏调用 svcCreateThread 时，宿主线程调度器通过 host/hle_guestthread.c 申请一个原生系统线程，为其初始化独立的 Horizon TLS 槽位，并赋予专有的调用栈。这种一一对应关系使得多核任务可以直接交由 Apple Silicon 的性能核（P-Core）与能效核（E-Core）由 iOS 系统内核进行原生调度，消除了所有调度损耗。

3.2 资源解析接管：zlib 与 Granny 3D 解码加速

在原版 Switch 游戏中，海量材质、角色模型与场景数据封装在暴雪自研的 CASC 容器中，且使用了大量的 zlib 压缩和 Granny 3D 骨骼数据段。

如果让这些解压操作在原始的虚拟化栈中运行，每次加载新场景都会出现明显的掉帧与卡顿。d2r-mobile 在宿主层强力拦截了资源解压函数：

hle_tact.c：拦截了资源块解压入口，直接调用宿主系统优化过的硬件加速 zlib 库，解压吞吐量飙升数倍；
hle_granny.c：将 3D 骨骼和动作解算的计算密集型子程序替换为宿主端精心优化的 C 语言实现，使得进入新场景与加载装备模型的 CPU 耗时降低至毫秒级。

4. 图形管线转译：从 Nvidia NVN 到 Apple Metal 与 TBDR 能耗优化

图形层的移植是整个工程中最富含技术含量的部分。Switch 的 GPU 基于英伟达 Tegra X1（Maxwell 架构），游戏使用的是任天堂与英伟达联合定制的专用底层图形 API——NVN。而 iOS 设备则完全基于苹果自研 GPU 与 Metal 图形框架。

4.1 强行拔除驱动：`nvnBootstrapLoader` 符号拦截

在正常的主机环境下，游戏二进制需要动态链接任天堂的图形驱动。但在 d2r-mobile 中，主程序仅导入了一个符号：nvnBootstrapLoader。宿主在 hle.c 中通过 HLE_FORCE 宏强制接管了这个函数指针查询入口：

// 强制替换图形初始化入口
void* host_nvnBootstrapLoader(const char* name) {
    // 拦截所有的 NVN 接口查询，直接返回宿主自研的桩函数
    return nvn_resolve_thunk(name);
}

这意味着官方 SDK 内的英伟达 NVN 驱动代码在 iOS 上一行都没有被执行。所有的 NVN 命令（如队列提交、状态绑定、常量缓冲更新）都被路由到 hle_nvn.c，并转换为宿主内部的轻量级命令中间表示。

4.2 离线着色器转译与 PSO 预热清单

动态编译着色器（Runtime Shader Compilation）是移动端游戏卡顿（Shader Stutter）的头号元凶。传统模拟器在玩家首次遭遇新怪物或新技能时，经常会由于后台临时编译 Shader 而瞬间冻结数十毫秒。

d2r-mobile 彻底摒弃了在线编译方案，构建了一套完备的离线工具链：

flowchart LR
    A["Maxwell GPU 机器码 (NVN Shader Binaries)"] --> B["Ryujinx 转译引擎 (C# / dmsh_xlate)"]
    B --> C["SPIR-V 中间表示"]
    C --> D["Metal Shading Language (MSL 源码)"]
    D --> E["Apple metalc 离线编译器"]
    E --> F["预编译库 (b-V/*.metallib)"]
    F --> G["运行时 pso_manifest.tsv 预热加载"]

在开发者执行 ./setup.sh 构建阶段：

离线工具链遍历游戏包内的全部 Shader，调用集成了 Ryujinx 转译核心的 dmsh_xlate 工具，将 Maxwell 架构的 GPU 微码逐个反编译并转译为 Apple Metal Shading Language（MSL）；
调用 macOS 的 metal 与 metallib 工具，直接生成能够在 iOS 上原生加载的二进制着色器库（存放在 b-<V>/ 目录下）；
生成完备的渲染管线描述清单 pso_manifest.tsv。在 App 首次进入游戏大厅前的 1 秒钟内，宿主提前预编译并烘焙好全部管线状态对象（Pipeline State Objects，PSO）。进入战斗后，所有的 PSO 都在 GPU 显存中就绪，真正实现了“零运行时编译，零掉帧”。

4.3 破解发热降频魔咒：TBDR 分块延迟渲染深度优化

移动端设备的物理功耗预算极为有限。英伟达 Tegra 采用的是传统的即时模式渲染（IMR），显卡每画一个三角形就直接向显存 Render Target 读写像素；而 Apple Silicon 的 GPU 采用的是典型的分块延迟渲染（TBDR）。

在 TBDR 架构下，GPU 会将屏幕切分为数千个 16x16 的片区（Tile），片区内的所有几何图元计算完成后在片上高速缓存（On-chip Tile Memory）中一次性完成光栅化，最后统一写回显存（Store）。如果直接将 NVN 的 RenderPass 逐字翻译为 Metal：

频繁的 RenderPass 切换会导致大量的 Load Action 与 Store Action；
每一帧都在反复往返主显存，引发严重的显存带宽拥塞，导致 iPhone 迅速发热降频。

flowchart TD
    subgraph IMR ["原生 NVN 行为 (即时模式 / IMR 逻辑)"]
        Pass1["Pass 1: G-Buffer 写入"] --> Mem1["全部附件全量写回系统显存 (Store)"]
        Mem1 --> Pass2["Pass 2: 后处理与光照"]
        Pass2 --> Mem2["从显存重新加载全部数据 (Load)"]
    end

    subgraph TBDR ["d2r-mobile 优化后 (TBDR 片上合并)"]
        MergePass["合并渲染通道 (tbdr_pass_merge.py)"]
        MergePass --> TileMem["在片上 Tile 缓存中直接流转中间数据"]
        TileMem --> DeadElim["消除未改写附件的 Store (tbdr_store_dead.py)"]
        DeadElim --> FinalStore["仅最终呈现帧写回显存 (LoadActionDontCare / StoreActionStore)"]
    end

为了彻底榨干 TBDR 架构的能效优势，d2r-mobile 自研了专用的通道分析器与优化器（tbdr_budget.py、tbdr_pass_merge.py、tbdr_load_dead.py 与 tbdr_store_dead.py）：

通道合并（Pass Merging）：通过静态依赖分析，将原本分离的几何渲染与中间遮罩合成合并为一个 Metal RenderCommandEncoder；
消除冗余加载/存储：将未被后续阶段读取的临时 Render Target 标记为 MTLStoreActionDontCare，并在进入通道时标记为 MTLLoadActionDontCare；
实测收益显著：在 iPhone 17 Pro Max 上的实测整机功耗从未经优化的 7.5W 骤降至 3.8W（60 FPS）；开启 30 FPS 省电模式时功耗更是低至 1.85W，能够连续畅玩近 5 小时！

4.4 纹理转码与老旧芯片（A16）兼容适配

Switch 大量采用了桌面级的 BC（Block Compression，BC1~BC7）压缩纹理格式以及 Nvidia 专有的 Swizzle 内存排布。然而，早期的 iPhone 芯片（如 iPhone 14 Pro Max 所搭载的 A16）并不支持在 Metal 中直接采样部分 BC 压缩纹理。

项目组在 dm/gfx/tex/ 中开发了硬件辅助的纹理反交错（GPU Deswizzle）与降级转码管道，并在构建期为 A16 及更早芯片生成了补充纹理包，保证了即使在 6GB 内存的 iPhone 14 Pro Max 上，游戏依然能够稳定以 60 FPS 满帧运行。

5. 原生触控交互重构与终局玩法生态

很多主机游戏移植到手机上最大的败笔，就是粗暴地在屏幕边缘贴几个透明的虚拟按键和死板的方向轮盘。d2r-mobile 贯彻了 “保留原版界面美学，用直觉手势取代按钮堆叠” 的理念，完全用纯原生代码重构了人机交互层。

5.1 指尖重构：手势驱动的人机交互

flowchart LR
    subgraph InputCapture ["触控采集与手势识别 (front_ios.m)"]
        Tap["单指轻触"]
        DTap["双指 / 双击"]
        Drag["按住并拖拽"]
        LPress["长按手势"]
    end

    subgraph ActionEngine ["动作解析引擎 (dm_actions.c / dm_cursor.c)"]
        Pathfind["全场景智能射线寻路 (点击 NPC / 地面 / 洞口)"]
        AimCast["技能拖拽全向瞄准 (动态辅助吸附)"]
        QuickSwap["副手技能一键切武器施法并回切"]
        InventoryOps["背包智能整理 / 双击装备 / 拖拽变卖"]
    end

    Tap --> Pathfind
    Drag --> AimCast
    DTap --> QuickSwap
    LPress --> InventoryOps

移动与寻路：左下角提供虚拟摇杆；玩家轻触屏幕上的 NPC、地面、洞口或传送门时，底层自动发射场景射线并计算最短寻路路径，角色会自动走到目标点并触发互动；
双轮盘与拖拽瞄准：战斗技能提供两组技能轮盘。轻按瞬发，长按并拖动摇杆即可 360 度精确指向施法，松手即释放；当附近有精英怪时，瞄准线具备智能微吸附特性；
副手技能一键穿透施法：对于“战争召唤（CTA）”等需要切副手吼血的技能，玩家轻点对应技能图标，底层自动完成“切副手 -> 释放技能 -> 立即切回主手”的连招宏，图标还会动态展示剩余充能量；
手势化背包管理：双击直接穿脱装备；将物品拖动到商人面板任意位置即可出售；长按空白格子一键自动排序背包；长按堆叠药水/卷轴弹出数量拆分；
手柄无缝热插拔：随时接入蓝牙手柄（Xbox / PlayStation / Switch Pro），UI 会在 1 帧内无感切换回主机版原生手柄界面与按键提示；手指再次触碰屏幕，又会瞬间切回触控模式。

5.2 突破 16:9 画布约束：全屏边缘铺满与 iPad 自适应

原版 Switch 游戏被硬编码为 16:9 比例（1280x720 或 1920x1080），在更宽比例的 iPhone（19.5:9）上往往会产生严重的左右黑边。

d2r-mobile 在 patch_nso.py 中对分辨率选择逻辑进行了精准补丁：

将原版编译器内联优化的固定掩码 mov w9, #0x740; and x9, x25, x9 替换为动态低 32 位读取 mov w9, w25; nop；
将画布宽度上限从 4560 放开至 0xffff；
使得游戏能够以 1956x900 或 2868x1320 的比例渲染，完美避开 iPhone 的灵动岛与圆角区域，实现震撼的端到端全屏铺满显示；在 iPad 4:3 屏幕下，UI 则会自动智能居中排布。

5.3 终局玩法创新：大秘境与 Boss Rush

在不改动暗黑 2 经典底层规则的前提下，d2r-mobile 在代码中植入了丰富的终局（Endgame）刷宝玩法：

大秘境（Greater Rift）：通过第五幕哈洛加斯的红色传送门开启。共设 100 层递增难度挑战，15 分钟内击杀秘境守护者即可通关。每通关 2 层奖励 1 个技能点与 5 个属性点，并将角色技能等级上限从 20 级解锁至 40 级；通关第 10 层更可为佣兵额外解锁 6 个装备插槽！
终局 Boss 连续挑战（Endgame Boss Rush）：地狱通关后解锁 12 阶段挑战，第 11 关为暗黑克隆体（Diablo Clone），第 12 关则直面地狱三巨头（Uber Tristram）；
极乐模式（Elysium Mode）：建角时可选的专属模式，暗金掉率提升 5 倍，绿色套装提升 3 倍，符文掉率提升 5 倍，Boss 击杀始终保持首杀掉落池；
击杀统计榜（Kill Board）：精确统计每一个 Boss 的击杀次数、首杀时间、平均击杀时长以及掉落暗金清单。

6. 严苛的质量守门体系：44 台内测设备通关地狱背后的测试基建

为了保证兼容层能够坚如磐石，d2r-mobile 在封闭内测中部署了 44 台不同配置的 iPhone 与 iPad 设备（从最低配的 iPhone 14 Pro Max 到搭载 M4 芯片的 iPad Pro），全部顺利打通了普通、恶梦、地狱全难度，且未发生任何崩溃。这一工业级稳定性的基石在于其完善的自动化回归系统。

flowchart TD
    subgraph Gates ["自动化质量守门矩阵 (Quality Gates)"]
        Gate1["regress.sh (AOT 指令等价性校验)"]
        Gate2["shotgate.sh (17 核心页面感知哈希截图守门)"]
        Gate3["touchchain.sh (确定性 Tick 触控链路回放)"]
        Gate4["savecmp.py (存档双向字节级等价性对比)"]
    end

    subgraph Oracle ["真值比对基准 (Ground Truth)"]
        Ryu["打补丁的 Ryujinx 模拟器 (驱动脚本)"]
        GDB["GDB 状态探针 (swgdb.py / swtick.py)"]
        Dump["生成 ticks.jsonl / c2s.jsonl / uimsg.jsonl"]
    end

    Ryu --> GDB --> Dump
    Dump --> Gate1
    Dump --> Gate2
    Dump --> Gate3
    Dump --> Gate4

整个验证工程涵盖四个硬核门禁：

指令等价性门禁（dm/verify/regress.sh）：借助 LLVM 工具链对每一个被重写的指令进行比对，验证替换后的跳转在任何寄存器状态下都满足语义等价；
像素级截图门禁（shotgate.sh）：在无头环境下渲染 17 个关键页面（背包、技能树、角色选择、各个幕场景），通过感知哈希算法对比参考图像，任何渲染破损或 UI 跑偏都会直接阻断流水线；
确定性触控链路回归（touchchain.sh）：触控用例脱离真实渲染帧率限制，以固定的服务器 Tick 为时钟推进，通过读取 ticks.jsonl、c2s.jsonl（网络发包序列）与 uimsg.jsonl 校验游戏逻辑状态流，确保测试结果不受机器负载波动的干扰；
存档字节级自洽性检验（savecmp.py）：每次运行结束后比对游戏存档结构，验证校验和算法与持久化序列化完全一致。

7. 架构启示：主机游戏移植的新范式

d2r-mobile 的工程实现为现代游戏逆向与跨平台移植领域树立了一个极具启发性的技术范本：

同构架构下的“去模拟器化”思考：当源平台与目标平台运行在相同物理指令集（AArch64）上时，强行套用 JIT 动态模拟不仅在 iOS 严格的沙盒下寸步难行，更是对 CPU 算力的巨大浪费。AOT 静态二进制修补 + 只读 Keypage 蹦床 提供了一条合法合规、完全符合代码签名且跑出裸机性能的捷径；
离线转译与 TBDR 协同是移动端能效的关键：GPU 移植不仅是 API 映射，更是体系结构的适配。通过离线着色器预编译消灭运行时编译掉帧，结合 TBDR 附件消除与通道合并，成功在 3.8W 超低功耗下驯服了主机级 3D 巨作；
软件工程质量压倒一切：稳定性不是玄学，而是严密工程体系的自然结果。完善的真值记录工具、基于服务器 Tick 的无头回放测试以及像素级截图门禁，使得复杂的逆向兼容系统具备了可追溯、可验证的工业级品质。

原文链接与参考资料

GitHub 官方仓库：jhaizhou-ops/d2r-mobile
免 Mac 离线打包与侧载指南：docs/NO_XCODE.md
游戏原始文件准备规范：docs/GAME_FILES.md
NVN 图形层与着色器转译链实现：dm/gfx/README.md
自动化验证与回归测试架构：dm/verify/README.md

lijianfei.com