RetroArch 1.22：libretro 参考前端，跨平台模拟器的统一入口

它解决什么问题，为谁而写

RetroArch 解决的问题很具体：模拟器生态碎片化。每个模拟器都有自己的窗口循环、输入处理、音频输出和配置格式，用户要分别学习、分别设置。RetroArch 作为 libretro API 的参考前端，把视频输出、音频输出、输入和应用生命周期全部接管，模拟器核心只需实现 libretro 的回调接口。这样做的直接收益是，一个前端可以加载任意 libretro 核心，从游戏机模拟器到 3D 程序都行。目标用户很明确：想在一个界面里管理多个核心的玩家，以及需要在多个平台（从 Android 到 Windows 11，甚至 DOS）上保持统一体验的开发者。文档强调它“small and lean”，但功能列表并不小，多 pass 着色器、实时倒带、FFmpeg 录制、run-ahead 输入延迟消除，这些都不是简单前端该有的东西。

libretro 接口：动态库是核心机制

libretro 是一个 API，定义了音频、视频和输入的回调。RetroArch 在运行时加载这些核心，核心是动态库，不是独立程序。文档说得很清楚：“These programs are instantiated as dynamic libraries”。这意味着构建 RetroArch 时不需要任何核心存在，核心在运行时按需加载。这种设计让前端和核心可以分别更新，但也带来了兼容性风险：核心和前端都各自演进，某个核心可能依赖特定版本的 libretro.h 头文件。API 头文件位于 libretro-common/include/libretro.h，这是所有核心的契约。前端负责生命周期，核心只负责计算。这个分离是 RetroArch 能移植到几十个平台的根本原因，因为平台相关的部分都被前端吸收了。

依赖是推荐而非强制，但音频驱动躲不掉

README 的依赖部分写得很微妙：“There are no true hard dependencies per se”。在 Windows 上，只需要 Win32；在 Linux 上，理论上什么都可以不装。但推荐依赖包括 GL 头文件、Vulkan 头文件、X11 或 EGL/KMS/GBM。真正躲不掉的是音频驱动，文档列出了一长串：ALSA、OSS、OpenAL、JACK、SDL、PulseAudio、PipeWire、XAudio2 等，至少需要其中一个。这意味着在最小化部署时，你仍然要选一个音频后端。对于嵌入式平台，比如 Miyoo 或 RetroFW，依赖由 SDK 提供，但这也意味着移植工作不是零。如果你想用着色器，显卡必须支持 OpenGL 1.1 以上，推荐至少 OpenGL 2.1 或 3.2。Vulkan 驱动则要求显卡支持 Vulkan 1.0。这些不是可选项，是硬性门槛。

配置从 config.def.h 开始，用户只需改差异

默认配置写在 config.def.h 里，README 明确警告不要随意改动这个文件。系统级配置文件安装在 /etc/retroarch.cfg。启动时，如果 $XDG_CONFIG_HOME/retroarch/retroarch.cfg 不存在，RetroArch 会自动创建它。用户只需要配置那些与默认值不同的选项。手柄配置可以通过内置菜单完成，也可以手动编辑 retroarch.cfg。这个设计很务实：默认值经过测试，用户改差异即可。但这也意味着，如果你要批量部署到多台机器，需要理解 config.def.h 里每个选项的语义，否则容易改出问题。命令行接口是完整的，这为脚本化配置提供了可能，但 README 没有给出具体命令示例，实际用法需要查阅文档中心。

着色器与菜单驱动：渲染 API 决定能力边界

着色器支持取决于你用的视频驱动。OpenGL 1.1 下没有任何着色器，菜单驱动只能用 RGUI 这类简单界面，XMB 因为缺少着色器管线而失去特效。OpenGL 2.1 可以用 NVIDIA Cg 着色器（已弃用，需要单独运行时）或 GLSL 着色器。OpenGL 3.2、Direct3D 11 和 Vulkan 都支持现代 Slang 着色器。这意味着，如果你想用最新的着色器效果，必须选择 OpenGL 3.2 以上的驱动或 Vulkan。菜单驱动方面，MaterialUI、XMB、Ozone 和 RGUI 在大多数驱动下都能工作，但 OpenGL 1.1 下 XMB 会失去部分效果。这个分层很清晰，但也是决策点：你的硬件决定你能用什么着色器。对于老设备，比如只支持 OpenGL 1.1 的显卡，你只能接受无着色器的现实。

平台覆盖是双刃剑，移植成本被隐藏

平台列表非常长，从 Android 2.x 到 Windows 11，甚至包括 DOS、PlayStation 2、Nintendo Switch 和 SerenityOS。这种覆盖度是 libretro 抽象层的功劳，但也带来维护负担。每个平台都有自己的 SDK 和依赖，文档说“Console ports have their own dependencies, but generally do not require anything other than what the respective SDKs provide”。这句话听起来轻松，实际意味着每个平台都需要单独的构建配置和测试。对于工程师来说，这意味着如果你要为一个新平台移植 RetroArch，你需要熟悉该平台的 SDK，而不是简单地复用桌面构建。另一方面，这种覆盖度也意味着，如果你在做一个冷门平台（比如 Haiku 或 ReactOS），你可能是少数用户之一，bug 修复可能不会优先。

替代方案：Standalone 模拟器与前端之争

与 RetroArch 形成对比的是 standalone 模拟器，比如单个的 Game Boy 模拟器或街机模拟器。这些模拟器自己处理视频和输入，不依赖 libretro。它们的优点是配置简单，每个模拟器只做一件事，版本更新独立。缺点是每个模拟器都有不同的 UI 和配置格式，用户要维护多个配置文件。RetroArch 的替代方案不是某个具体产品，而是一种思路：要么接受碎片化，要么统一到 libretro。如果你只需要一个模拟器，standalone 可能更省事，因为你可以跳过前端的学习成本。但如果你要玩多个平台的游戏，RetroArch 的统一切换核心能力就体现价值。文档提到还有“several other projects have used the libretro interface”，这意味着前端不是唯一的，但 RetroArch 是参考实现，功能和兼容性通常最先到位。

维护与许可证：GPLv3 的约束

RetroArch 采用 GPLv3 许可证，这是一个强 copyleft 许可证。如果你分发修改后的版本，必须提供源代码，并且衍生作品也必须以 GPLv3 发布。对于商业项目，尤其是闭源项目，这是一个硬性约束。文档没有提供法律建议，但许可证是明确的。维护方面，项目活跃，最近发布 v1.22.2，2025 年 11 月仍有推送。这意味着 bug 修复和功能更新是持续的。但维护成本在于，你需要跟随上游更新，因为核心 API 可能变化。如果你自己维护一个 fork，你需要跟踪 libretro.h 的变化。构建 RetroArch 需要编译 C 代码，桌面平台依赖较少，但控制台平台需要对应 SDK。升级路径是存在的，但你需要定期检查 release notes，因为配置选项可能会变。

编辑结论

RetroArch 适合需要统一管理多个模拟器核心、并追求跨平台一致性的个人用户或嵌入式设备开发者，尤其当你希望在一个界面上处理视频、音频、输入和着色器时。不适合那些只需要单个模拟器、且不愿处理核心版本兼容性的场景，也不适合对 GPLv3 许可证敏感的商业闭源项目。采用前应验证三件事：目标平台是否有可用的核心二进制，你的显卡驱动支持哪种渲染 API（Vulkan、OpenGL 3.2 或 Direct3D 11），以及你能否接受核心与前端版本之间的匹配风险。RetroArch 的架构决定了它不是一个即插即用的模拟器，而是一个需要投入配置时间的平台。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes