在掌机发展史上，Nintendo DS 的双屏设计曾催生出无数创意应用，但要在其仅有 66MHz 的 ARM9 处理器上实现一套完整的编程环境，绝非易事。开发者 Carl Enlund 用约 3100 行 C 代码打造了一款运行在 DS 上的可脚本化 3D 游戏引擎，成功将代码编辑器与游戏引擎合二为一。本文将从系统架构的角度，解析其双屏协同机制、脚本解释器的实现细节，以及在资源受限环境下保持 60FPS 的工程策略。
双屏协同架构：软硬件渲染的任务分离
DS 的硬件特性决定了架构设计的核心约束。ARM9 主处理器需同时驱动两块分辨率仅为 256×192 的屏幕，且下方屏幕缺乏 3D 硬件加速能力。该引擎将渲染任务进行了物理隔离：上方屏幕承担 GPU 加速的 3D 渲染，下方屏幕则采用纯软件绘制实现交互式代码编辑器。
在上方屏幕的 3D 渲染管线中，引擎直接调用 libnds 封装的 OpenGL ES 子集接口。每个渲染帧的执行流程如下：首先通过 glMatrixMode(GL_MODELVIEW) 切换至模型视图矩阵栈，随后调用 glLoadIdentity() 重置矩阵，再利用 gluLookAt 设置相机位置与朝向。接下来遍历所有激活的模型对象，对每个对象执行 glTranslatef 位移变换和 glRotatef 绕 Y 轴旋转变换，最后调用 drawCube 绘制立方体几何体。立方体采用 RGB15 颜色格式，通过 glColor3b(r*255/31, g*255/31, b*255/31) 进行转换，每面由 4 个顶点组成 GL_QUADS 图元。
下方屏幕的编辑器则完全依赖软件渲染。引擎通过 BG_BMP_RAM_SUB(0) 获取下屏帧缓冲区的基址，按像素逐点写入颜色值实现 UI 绘制。这种方案的计算开销集中在 CPU，但考虑到下屏仅需绘制简单的 UI 控件与文字令牌，在 66MHz 频率下仍能维持流畅响应。编辑器的交互逻辑被设计为事件驱动模式：触控笔点击触发令牌插入，数字键盘修改数值参数，寄存器选择器切换目标变量。
令牌式脚本语言的设计与解释器实现
该引擎采用了一种极简的自定义脚本语言，完全摒弃了字符串解析的开销。脚本由一系列「令牌加参数」的指令序列构成，每行对应一个原子操作。解释器在执行时无需词法分析或语法树构建，仅需通过 if(tokenEquals(script[scriptIP], "add")) 这类结构进行指令分发。这种设计使得每帧可稳定执行约 60 条指令，且不存在动态内存分配，规避了嵌入式系统中常见的内存碎片问题。
脚本语言的核心数据结构包含 26 个通用寄存器（A 至 Z）以及 9 个只读寄存器。只读寄存器映射了硬件输入状态：D-pad 方向键返回 1.0 或 0.0 的浮点值，A/B 按钮同理；TIME 寄存器记录脚本启动后的 elapsed seconds；LOOKX 与 LOOKZ 则存储相机朝向向量。指令集覆盖了基础算术（SET、ADD、SUBTRACT、MULTIPLY）、控制流（LOOP/END_LOOP、IF_GT/IF_LT/IF_TRUE/END_IF）以及 3D 渲染控制（MODEL、POSITION、ANGLE、CAM_POS、CAM_ANGLE）。
解释器的执行循环以帧为调度单位。伪代码逻辑如下：检查当前程序计数器指向的令牌类型，若匹配 ADD 则将目标寄存器的值加上参数；若匹配 LOOP 则将循环起始地址压栈；若匹配 IF_GT 则比较寄存器值与阈值，仅在条件为真时继续执行块内指令，否则跳转至匹配的 END_IF。这种设计天然支持了实时热重载：用户在下屏修改脚本后，点击「Play」即可立即看到逻辑生效，无需重启 ROM。
跨平台 ROM 构建与实机部署流程
该引擎的编译环境基于 devkitPro 工具链，包含 devkitARM 交叉编译器与 libnds 库。开发者仅需在 Linux/Windows 上安装 devkitPro，下载包含 main.c 与 Makefile 的源码包，执行 make 即可生成约 100KB 的 .nds ROM 文件。源码中所有 3D 模型数据、编辑器 UI 资源均以内联数组形式硬编码，避免了外部依赖管理的复杂性。
实机运行需借助烧录卡（如 R4、DSTT、Acekard 等）。将编译产物拷贝至烧录卡的 microSD 卡根目录，插入 DS 后从烧录卡菜单启动即可。若需调试，可使用开源的 BlocksDS SDK 进行仿真测试，该 SDK 提供了完整的文件系统支持（FAT）与 NitroFS 打包方案，便于在 PC 端验证逻辑正确性后再部署至真机。
值得注意的是，DS 的 ARM7 协处理器负责音频与部分输入响应，而 ARM9 主处理器承担主要计算任务。引擎的脚本解释器完全运行于 ARM9，仅在调用 BEEP 指令时通过硬件抽象层向 ARM7 发送声效触发请求。这种双核协作模式在后续的自制开发中被广泛采用，成为 DS 逆向工程与 ROM 修改的基础范式。
工程化启示与局限边界
该项目的设计哲学在于「用约束换取确定性」。128 行脚本上限与 16 个 3D 模型的硬性限制，消除了动态资源管理的复杂度；无字符串变量、无函数调用的语言特性，确保了解释器的实现代码可控制在数百行以内。这种「小而美」的架构思路，对于资源受限场景下的快速原型开发具有借鉴意义。
然而，其局限性也显而易见：缺乏函数调用意味着代码复用必须依靠复制粘贴；每帧一条指令的执行粒度限制了复杂物理模拟的可能性；软件渲染的下屏在大量 UI 更新时可能出现帧率抖动。若需扩展至更复杂的游戏类型（如 RPG 或 ACT），需重新设计虚拟机指令集并引入 JIT 编译或字节码优化。
该项目展示了在掌机平台实现「代码即游戏」的可行性路径。双屏分工的硬件设计为软件架构提供了天然约束，而令牌式解释器的轻量化实现则证明了「无解析器」脚本语言的工程价值。对于研究复古平台逆向工程或嵌入式脚本系统的开发者而言，这套架构提供了从硬件交互到用户交互的完整参考范式。
参考资料：
- DS code editor & scriptable game engine: https://crl.io/ds-game-engine/
- BlocksDS SDK 文档: https://blocksds.skylyrac.net/