让二十年前架构最古怪的家用游戏机，在一台普通笔记本的 Chrome 浏览器里跑满原生帧率，听上去像是某种概念演示。
开发者 snuri00 近日在 GitHub 开源的项目 ps2-web-recomp，把这个场景变成了现实。根据作者公布的实测结果，《GT赛车4》PAL 版本在笔记本核显环境下开出双倍分辨率，能够稳定跑满 50 FPS，经过管线调优后，在 3 倍分辨率下依然维持在 48–50 FPS；而以高压战斗场景著称的《战神2》，在原生分辨率下同样打满 60 FPS，双倍分辨率下也能达到 48–60 FPS。该项目以 MIT 协议开源，仅包含重编译器与运行时代码，没有任何游戏版权文件，构建过程需要开发者在 Linux x86-64 环境下传入自备的合法 ISO 镜像。
这引发了广泛的技术讨论：在没有任何独立模拟器客户端的前提下，浏览器到底是怎么啃下索尼这块著名的异构硬件硬骨头的？
绕过 JIT 虚拟机的静态重编译
了解 PS2 历史的人都清楚，它的核心硬件是一座由非标组件堆砌的迷宫。主芯片 Emotion Engine 包含定制的 MIPS R5900 核心，带有非标准的浮点运算和独特的多媒体指令，外挂两个被称为 VU0 和 VU1 的向量计算单元，以及一个拥有专属显存排布的图形合成器（Graphics Synthesizer）。
二十多年来，像 PCSX2 这样的通用模拟器主要依赖动态重编译（JIT）或逐条解释执行。这种方案在运行时动态翻译代码，跨平台转换开销极大，还伴随着难以抹平的线程同步延迟。
ps2-web-recomp 换了一条思路。它借用了近期在逆向工程界走红的静态重编译（Ahead-Of-Time）路线：在游戏运行之前，静态分析工具 eerecomp 先将游戏光盘中的机器码直接逆向并翻译成对应的 C++ 代码，随后编译为 WebAssembly（Wasm），最终与一个用 WebGPU 重写的运行时链接在一起。
机器码变成了可以直接在浏览器内原生运行的代码逻辑，省去了中间层解释器反反复复的取指、解码过程。
与此同时，图形端交给了现代浏览器里支持度正在扩大的 WebGPU。PS2 的 4MB 专有显存被映射进 GPU，三角面光栅化全部由 WebGPU Compute Shaders 接管。在项目初期，使用软件光栅化与解释器时，《GT赛车4》原生分辨率下只能跑出惨淡的 3 FPS。但当计算着色器介入、管线批处理被重构后，性能直接跃升至原生满帧之上的 70 FPS。
其中最核心的优化之一，是渲染调用的合并。首个 GPU 渲染版本每帧要向浏览器提交约 650 次计算调度（Compute Dispatches），因为任何一次纹理上传都会打碎当前的三角形绘制批次。作者将不产生依赖的纹理上传提前批处理，把每帧调度次数骤降到约 80 次；再配合一个 16 MB 的 GPU 显存缓存层，让原本每帧都要向显存回写 3 MB 纹理的《GT赛车4》直接减少了 60% 的跨线程数据传输。
所谓「无需模拟器」的技术文字游戏
项目在社区发布后，最引人瞩目的标语莫过于那句“without an emulator”。很多人下意识地以为，Web 技术已经强大到可以直接把主机游戏当成本地单机程序编译运行。
然而事实远没有这么简单。
所谓的静态重编译，消灭的只是指令解释循环，从没有真正消灭模拟器本身。
细看 ps2-web-recomp 的系统架构，它之所以能工作，依然依赖一个庞大而精密的宿主模拟层：
- 高层内核模拟（HLE）PS2 的操作系统调用、DMA 控制器、垂直消隐中断和主从处理器通信协议，全是由 C++ 重新模拟出来的。
- IOP 处理器上的传统解释器游戏光盘自带的声卡驱动、文件流读取和外设控制，依然跑在一个专门解释执行的 R3000 CPU 模拟器中。
- 未覆盖代码的动态补救机制当游戏遇到静态分析没能捕获的全新 VU1 微程序时，运行时依然会在几毫秒内现场动态生成 Wasm 模块（这本质上依然是 JIT 行为）。
它不是不需要模拟器，而是把传统模拟器拆解了。原本由虚拟机承载的运算负载，被拆散成了转译代码与高度定制的硬件垫片。
这也解释了为什么这类项目极其难以大规模通用化。当作者从第一款跑通的《GT赛车4》转向第二款游戏《战神2》时，仅仅在初始化阶段就踩出了一连串暗坑：声卡驱动因为硬件计时器未实现而陷入死寂；画面出现大面积错乱的拉伸多边形；游戏甚至在进入战斗前直接内存越界崩溃。
排查后发现，问题全在极端底层的时序细节上。《战神2》的代码在发出剪切指令（CLIP）后仅隔 3 条指令就读取标志位，而项目此前的硬件模型在第 4 条指令后才允许标志位可见——在《GT赛车4》里完全合法的微程序，换到《战神2》就成了致命漏洞。
- 风险.静态重编译无法回避不同游戏对非标准浮点舍入和芯片管线时钟周期的严苛依赖，每多移植一款复杂大作，都可能演变为一次漫长的人肉硬件行为排障。
更现实的制约在于浏览器的兼容门槛。目前能够原生支持 WebGPU 的仅有 Windows 和 macOS 平台下的 Chrome 与 Edge。如果在 Linux 环境下运行，读者必须手动进入浏览器实验页面开启 #enable-unsafe-webgpu 和 #enable-vulkan 标记；一旦缺失 WebGPU，系统只能回退到慢如定格动画的软件光栅化模式，根本无法进行正常 3D 游戏。
此外，作者公布的帧率均来自特定笔记本核显测试，并未公开严谨的硬件对比变量与第三方可复现基准。离开那块核显，在移动端或跨芯片平台下的稳定性依然有待观察。
撕开缝隙的软件分发新形态
如果仅仅把 ps2-web-recomp 当作一个怀旧玩具，就低估了它的技术意味。
它真正打破的，是浏览器处理复杂桌面级工业资产的算力边界。过去很长一段时间，WebAssembly 和 WebGPU 在主流商业舆论里，大多局限在轻量级 3D 看板、轻办公协作或简单的云原生工具上。但两款 PS2 标杆游戏以 60 帧的状态跑进浏览器，证明了一条可行路径：只要编译期足够重，原本需要庞大系统权限与深度环境绑定的沉重旧软件，完全可以被抹平分发壁垒。
这给主机厂商和版权方带来了全新的麻烦。在现有法律框架下，重编译工具链本身不包含任何游戏素材和二进制，受 MIT 协议保护；但通过几条自动化脚本，用户本地持有的盘片镜像就可以在三分钟内变成一个随时可通过网页访问的单页应用。传统的平台护城河和商店封禁，面对一个基于标准的 WebGPU 画布，几乎找不到有效的拦截靶点。
行百里者半九十。静态重编译给经典软件保护打开了一扇门，但它绝非通用模拟器的替代者。它更像是一把昂贵的手术刀：为特定的几款传世之作手工打磨管线，换取惊人的终端轻量化；而剩下的几千款游戏，依然得老老实实躺在通用模拟器的虚拟机里等待周期对齐。
接下来真正值得关注的，不是作者又修了几个时序 Bug，而是第三款、第四款商业大作被推进这套流程时，究竟需要付出多高的工程人月。