将经典射击游戏移植到芯科科技MG24 Matter开发板

Silicon Labs（芯科科技）热衷于突破嵌入式系统的极限和创新。在先前成功将一款经典游戏－雷神之锤（Quake）移植到基于EFR32MG24无线SoC的Arduino Nano Matter 开发板之后，我们迎来了新的挑战：将另一款经典第一人称射击游戏－毁灭公爵3D（Duke Nukem 3D）的完整体验带到我们的超低功耗平台MG24的开发板上，以实现包括游戏音乐、多人连线模式等完整的游戏玩法。

为什么选择毁灭公爵3D

毁灭公爵3D于1996年在Quake之前发布，是互动玩法的里程碑。虽然在图形上不如Quake先进，但它提供了：

可移动的墙壁和区域

与物体交互以及可破坏的环境

高级功能：镜子、安全摄像头、脚本控制和混响效果

这些特性使它成为一个完美的参考设计，用来展示嵌入式性能和游戏体验的完整性。

硬件限制与游戏特性

我们希望代码能运行在去年为Quake移植开发的同一款开源硬件上，也就是“The Gamepad”，它基于Arduino Nano Matter板，搭载基于芯科科技MG24 SoC的MGM240S无线模块。

The Gamepad硬件规格：

无外部RAM（仅使用MGM240S内部的25kB）

外部闪存用于数据存储（最高 64 MB）

320 × 240 像素RGB IPS LCD，带SD卡读卡器

立体声音效

模拟摇杆和16个按键

代码库

我们选择了Chocolate Duke Nukem 3D，它是 Fabien Sanglard 的 xDuke 移植版本的精简和注释版，并支持 SDL。SDL 支持让我们可以在 Windows 上开发和优化，然后再移植到真实硬件。

我们针对内存和速度进行了大量优化，以适应256 kB RAM 的限制。

内存优化

原始毁灭公爵3D需要8 MB RAM，远超我们的硬件条件，因此必须进行深入优化。主要措施包括：

根据性能分析和代码检查，优化结构体字段大小

将关卡常量数据存储到闪存，减少RAM 占用

创建分配器，仅存储修改过的对象，未修改的对象直接从闪存读取

将部分静态全局数组移到栈上

重用大型全局缓冲区（例如在关卡加载时重用帧缓冲）

优化插值算法

游戏动画渲染时，从外部闪存分块复制到RAM，再进行渲染

脚本文件预编译并作为常量数组存储在代码中

摄像机精灵（显示安全摄像头画面）临时渲染到帧缓冲的状态栏区域，因此每次渲染后必须重新绘制状态栏

优化声音引擎，减少冗余RAM 使用

将xDuke 的高级混响效果替换为原版Duke Nukem 3D 的简单混响

速度优化

为了提升性能，我们采取了以下策略：

重写部分绘图例程。原始代码是高度优化的x86 汇编，后来在xDuke 中通过自动工具转换为C，导致代码难以理解且性能下降。

由于墙体和精灵是逐列绘制的，我们利用DMA在当前列绘制时从外部闪存加载下一列，实现加载与渲染并行，减少等待时间。

基于802.15.4无线连接的多人模式

我们采用芯科科技的RAIL库构建了一个轻量级协议：

异步节点发现：在初始阶段，所有节点选择一个随机地址，并通过“问候”数据包进行广播。一旦其他节点接收到这些数据包，网络就形成了。

同步的类令牌环通信：当所有玩家都确认准备好比赛后，协议切换到同步模式。在此模式下，地址最小的节点被选为主节点。主节点每隔25毫秒启动通信，第二个节点（地址次小）广播其数据，然后第三个节点发送，最后第四个节点广播自己的数据。协议支持自动重发丢失的数据包，以确保可靠性。

工具与脚本

我们使用了一个 Python 脚本来转换GRP文件，使其满足以下要求：

所有 MIDI 文件转换为 Type 0 格式

VOC文件转换为更易处理的 WAV 格式

GRP文件必须存储在 SD 卡中。通过在开机时按下特定按键组合，文件会被复制到外部闪存。Atomic Edition 需要 2×32MB闪存芯片，而原始版本只需2×16MB 芯片。

性能亮点

超频情况下：30–50 fps

未超频情况下：18–30 fps

由于引擎更简单，DN3D 比Quake更快

结论

此移植展示了芯科科技MG24无线SoC的强大性能与灵活性：

在受限硬件上运行完整功能的经典复古第一人称射击游戏

支持多人模式、音乐、存档/读取以及控制台功能

高效的内存管理与性能调优

我们希望这能激发开发者探索嵌入式平台的更多可能性——无论是游戏、可穿戴设备，还是下一代物联网。