Xbox经典冒险游戏合集亮相

背景

本文作者是Xbox旗下的一名雇员，但明确声明这篇帖子完全是个人兴趣项目，与Xbox公司无关，未获得任何资金、硬件或文档支持。该项目是其更大个人项目（从零编写游戏引擎）的一部分，早在加入Xbox之前就已经启动。所使用的硬件是从eBay上购买的初代Xbox（Xbox OG）。

初代Xbox不仅是作者个人最钟爱的游戏主机之一，也是他最欣赏的开发硬件/环境之一。当作者开始将原本仅基于Vulkan、面向PC的Mirage引擎改造成一个具备良好分层、能轻松支持任意平台和任意渲染API的通用引擎时，他想到的不仅仅是支持Xbox One、PS4乃至即将发布的新世代主机（Xbox Series和PS5），而是更远的过去——他希望原生支持一些较老的游戏主机/掌机，其中就包括初代Xbox。将如此古老的硬件作为现代开发的目标平台，正是作者喜欢的那种挑战。

核心内容

挑战：将现代引擎移植到已死的硬件

作者面临的第一个核心问题是：他的引擎原本基于Vulkan、仅支持Windows/Linux、使用C++17（后升级到C++20）、以及当时的CMake 3.x版本，并运行在Visual Studio 2019上。而初代Xbox的开发环境要求最多只能使用C++98或C++03、最古老的CMake（1.4.x左右）、Visual Studio 2003，并且需要支持一系列不同格式的文件。

为了适配，作者不得不将引擎中所有C++17到C++98之间特性的代码重写或移除，重新适配整个引擎API，禁用部分功能并添加独家特性。更麻烦的是，MSVC编译器无法编译C++14之前的C++代码，因此作者不得不在Windows 11环境下使用VSCode和GCC来测试编译，确保代码正确后，再将其“送回”到Windows XP电脑上进行重新编译和运行。通过CMake的presets功能，作者可以在主Windows PC上同时生成和编译针对不同C++版本和API的配置，然后再迁移到古老操作系统上针对硬件构建和测试。

为何不使用现成的开源方案？

作者知道nxdk以及其他优秀的开源自制项目（针对Xbox、N64、Dreamcast等）。但他个人有两点偏好：

1. 阅读官方文档：作者喜欢深入阅读特定硬件的官方文档（SDK/API文档）、官方示例并从中学习技巧。Xbox在整个生命周期中提供了优秀的文档和示例，这吸引了他。
2. 按平台预期的方式开发：作者喜欢使用目标平台原生的工具链和环境进行开发。即使能直接使用C++23，他也认为对于这类个人爱好项目不合适（商业项目则另当别论，因为有时商业项目有预算和时间限制）。

具体案例：加载 Sponza 场景

作者的目标是让引擎在初代Xbox上运行经典的Sponza演示场景。主要难点在于：

• 文件大小问题：原始Sponza的OBJ文件约为23.29MB，但直接转换为Xbox格式后变成了82.3MB，这甚至超过了初代Xbox的全部内存容量。为了使其可接受，作者不得不降低多边形数量（但视觉上在当年尚可接受）。
• 格式转换链：作者需要将Sponza从FBX格式转换为OBJ（因为OBJ是纯文本格式，在时间维度上非常可移植）。但当时Windows 11上的Blender/Maya只能导出最低FBX2011版本，而这无法导入到2000-2005年的XP环境中的Maya（Blender当时没有FBX导入器，3dsMax只支持*.3ds格式）。所以OBJ成为唯一选择。
  • 第一步：在Maya 6.5中打开OBJ进行优化（Maya 6.5的导出工具和几何工具当时最好）。
  • 第二步：将优化后的OBJ导入Blender 2.3，利用Blender将几何体转换为DirectX 8的.x文件格式。
  • 第三步：手动编辑.x文件，清理其中的“null”值（否则后续步骤会出错）。
  • 第四步：使用Xbox SDK中的转换工具（convx）将.x文件转换为二进制压缩的.xbg（Xbox geometry）文件。有趣的是，这个工具至今仍能在Windows 11 + DirectX 12下运行。
• 文件大小对比：最终压缩的.xbg文件大小约为2.9MB（简化版），而原始Sponza从GitHub下载的zip包含纹理约109.9MB（不含纹理23.29MB）。
• 为何跳过3dsMax：初代Xbox的工具集本可以直接从.3ds转换为.x，但当时Discreet的3dsMax 6.0无法接受FBX且OBJ加载经常损坏，因此只能用Maya+Blender的路线。

最终，初代Xbox分支的加载代码可以正常工作——在现代系统上读取.fbx，在初代Xbox上读取.xbg。

关键要点

• 硬件死亡带来的挑战：初代Xbox已经没有任何官方支持，只有过时的SDK、文档，以及陈旧的要求、工具链和工具，与现代软件创建流程严重不匹配，甚至无法在最新操作系统（Windows 10/11或Linux）上友好运行。
• C++标准降级：从C++17/20回退到C++98，必须重写大量函数、重新适配引擎API。
• 编译器限制：MSVC无法编译C++14之前的代码，为在Windows 11上测试不得不使用GCC，再迁移到XP环境编译。
• 文件格式转换的复杂性：从现代FBX到老旧.xbg中间经过多步软件（Maya、Blender）和手动编辑，任何一步出错都会导致失败。
• 对官方SDK的依赖：作者坚持使用官方工具链和文档，不使用nxdk等开源方案，以保持“原生”开发体验。
• 个人项目与商业项目的区别：商业项目有预算和时间约束，可能会采用更简单的方案；而个人项目可以追求自己喜好的方式。

意义与影响

这篇文章展示了在现代技术环境下逆向移植游戏引擎到二十年前死亡硬件的极端挑战，同时也体现了游戏开发者对经典平台的热爱和极客精神。它提醒我们：

1. 向后兼容的难度：即便同一家公司（Xbox）内部，现代工具的更新已经使得旧平台的支持变得几乎不可能，需要大量手动工作和创造性的变通。
2. 官方文档的价值：尽管硬件已淘汰，但官方SDK和文档依然可以为爱好者所用，且作者认为它们质量很高，值得钻研。
3. 开源方案的取舍：作者并非不知道开源方案（如nxdk），但个人偏好决定了开发方式。这反映了开发者社区中关于“原生”与“模拟/兼容”开发的不同哲学。
4. 对游戏历史保护的意义：这种个人项目实际上是在为老平台保留和创造新的运行内容，有助于延长经典硬件的生命力和文化价值。同时，它也提醒硬件厂商和开发者：长期支持旧平台需要投入巨大精力和成本。

总之，这篇帖子不仅是技术细节的分享，更是一份对初代Xbox的致敬——即使它早已被遗忘，仍有人愿意为它倾注热情和时间。