将经典射击游戏移植到芯科科技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的强大性能与灵活性：

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

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

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

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