Picophysics 这个名字指向的是一个给 N64、PSX、Dreamcast 这类旧游戏平台准备的“单文件物理引擎”。它要解决的是复古自制游戏开发里最容易卡住的一环在内存紧张、CPU 主频不高、工具链古老的环境下把刚体运动、碰撞检测、重力这些基础物理能力用尽量小的代价嵌进 ROM 项目。这个主题最值得看的并不是物理效果有多花哨而是“单文件、无依赖、能编译进旧平台”的工程组织方式。如果你正在写 N64 自制游戏或者想给 PSX 项目加一点碰撞和跳跃手感又或者在 Dreamcast 上想快速做个平台跳跃 Demo这篇内容会比较合适。下面先讲清楚这类开源库的适用边界再按开发流程拆解环境、最小示例、核心参数、跨平台移植和问题排查。1. 为什么旧游戏平台会需要单文件物理引擎1.1 复古自制开发的真实环境写 N64、PSX、Dreamcast 自制游戏和现代 Unity、Unreal 开发完全是两个世界。最后代码会直接编译成 ROM 或 CD 镜像跑在几十 MHz 的 CPU 上内存按 MB 算。PC 上随便开几十个对象做物理几毫秒就完成的一件事放到这些平台上就需要认真考虑对象数量、数据结构、浮点运算成本甚至堆栈长度。几个硬条件先摆出来N64MIPS 架构主机内存通常只有 4MB 到 8MB。纹理、模型、代码、堆分配都挤在这几 MB 里物理引擎的内存占用不能太大。PSXMIPS R3000 衍生 CPU主频大概在 33 MHz 级别内存 2MB 左右显存 1MB。很多自制项目会刻意避免动态内存分配。DreamcastSH-4 架构主频 200 MHz 级别内存 16MB比前两代宽裕一些但同样不是现代开发机能比。在这些平台做游戏物理库如果自带几十个依赖文件光适配工具链就能消耗掉大半天。单文件方案的价值就在这里一个头文件加一个 C 文件或者一个实现型头文件整个工程里包含进来就能用。N64 的 libdragon、PSX 的野火 SDK、Dreamcast 的 KallistiOS都只提供基础入口、图形和输入输出没有完整物理系统。要实现主角跳跃、敌人碰撞、平台移动最省事的方式就是找一个小型单文件物理方案自己融进去。1.2 “单文件”到底省在哪里单文件物理引擎的实际好处可以归纳成几点编译集成成本低。你不用处理多个头文件的依赖继承不用把一堆静态库链接进 ROM不用做复杂的条件编译。把 C 文件拷到源码目录在工程里包含头文件编就完了。行为透明。整个物理逻辑只集中在一个文件里调试时可以直接阅读求解器循环修改碰撞回调不用在多个模块间跳来跳去。可改性强。旧平台没有统一物理规则你要的是“这个游戏玩起来手感对”不是“物理库所有功能都齐全”。单文件方便你删掉用不到的代码压缩体积。但这里要提醒一句单文件不等于“完成一切”。它一般提供的是 2D 或简化 3D 的刚体、圆形、AABB 或球的碰撞、重力和简单约束。如果你想做布料、软体、复杂关节链大概率需要自己扩展。Picophysics 这类项目核心目标是“够用 能放进旧平台”而不是做成通用物理大引擎。1.3 常见误解旧平台不能跑物理一个比较常见的误解是N64 和 PSX 这么老的机器跑得动物理吗实际上平台跳跃、弹跳球、方块解谜、2D 格斗、简单 3D 刚体掉落这些场景在旧平台上完全跑得动。所谓“跑不动”多数是因为对象数量没控制住或者用了高成本的凸包碰撞、连续碰撞检测、关节约束。这类需求本来就不属于轻量单文件物理的适用边界。我把这类引擎的定位总结成一句话它适合“规则简单、对象几十到几百个、不需要精确模拟”的游戏玩法。如果你要做严谨的车辆模拟或者角色身体由多个刚体关节组成建议换更完善的库或者自己扩展约束求解器。2. 使用单文件物理引擎的边界和取舍2.1 能解决什么不能解决什么先看能解决的部分重力影响下的物体下落。圆形、矩形或圆形刚体之间的碰撞。简单反弹、摩擦、地面支撑。触发检测比如玩家进入某个区域触发开关。很短链的简单约束比如弹弓、绳索的简化版本。再看不能解决的部分高质量 3D 人物物理需要多个约束和姿态控制。布料、流体、软体变形。大型物理场景对象数量动辄上千。连续碰撞检测防止高速子弹穿透薄墙。针对复杂关节的逆运动学。这不是“能力不行”而是设计目标不同。单文件物理库优先保证代码量小、逻辑简单、容易编译。你在选型时先列需求再决定是否够用。2.2 为什么不要一开始就把参数拉满我见过不少人拿到一个物理引擎第一件事就是加 500 个物体然后开满摩擦、反弹、关节跑起来发现卡顿或者穿模立刻得出结论“这库不行”。实际上旧平台物理的调试顺序应该是从小到大。我建议第一次测试分三步走只用一个球从固定高度掉落看它落到地面上是否弹跳正常。用 16 个对象做混合碰撞观察是否穿透、是否震动。再逐步加对象直到 CPU 占用和内存占用达到你的预期上限。不要一上来就开最大数量。低配平台能跑多少和物理库本身关系不大更多取决于你的数据结构和更新频率。2.3 单文件方案的主要风险单文件物理引擎也有明显风险需要提前知道。第一是功能固化。如果你需要的功能库里没有自己改起来可能比重新写一个更费劲。单文件的逻辑往往和其他代码耦合很深阅读成本不低。第二是精度和确定性。旧平台编译器的浮点行为、指令顺序可能影响物理模拟结果。同一个物理库在 PC 上表现正常移植到 MIPS 或 SH-4 平台上结果可能不一样。不是库有问题而是浮点运算在目标平台上的实现差异。第三是内存策略。很多单文件库为了简单会使用固定数组或无限制的全局对象池。如果你在工程里动态创建和销毁对象需要确认库是直接管理数组还是通过 id 管理对象。id 复用和数组越界是常见坑。旧平台开发里内存占用本身比 CPU 占用更容易被低估。你写了一个看似精简的物理库但如果每个对象都用了较大的结构体几百个对象也可能吃掉几十 KB放进 4MB 的总内存里仍然需要精打细算。3. 在开发机上先跑通最小示例3.1 环境选择和编译方式不需要一开始就为 N64 或 PSX 配置交叉编译环境。标准的做法是先把物理库在 PC 上编译成命令行工具用一个小 Demo 验证基本功能。这样调试快、日志方便、内存问题容易复现。推荐环境是 Linux 或 macOS配合 GCC 或 Clang。Windows 下用 MSVC 也能编但需要留意库是否用了 POSIX 风格的时间函数。单文件库一般只依赖 C 标准库跨平台问题不大。先创建一个测试目录结构大概是这样picophysics_test/ picophysics.h picophysics.c demo_main.c Makefile这里只是通用结构示例具体文件名称以你下载到的源码为准。Makefile 只需要简单编译规则CFLAGS -stdc99 -Wall -O2 LDLIBS -lm demo: demo_main.c picophysics.c $(CC) $(CFLAGS) -o $ $^ $(LDLIBS)如果你的目标平台工具链只支持 C89那需要把-stdc99改成-stdc89或直接不指定。很多复古平台 SDK 的编译器版本较老C99 特性不一定全支持。3.2 最小可运行示例下面这个示例主要是演示物理引擎的典型使用流程不代表 Picophysics 的真实 API具体接口要以你拿到的头文件为准。流程是关键#include picophysics.h #include stdio.h int main(void) { struct PFWorld *world pf_create_world(); struct PFBody *ball pf_add_body(world); pf_set_position(ball, 0.0f, 10.0f); pf_set_shape_circle(ball, 0.5f); pf_set_density(ball, 1.0f); struct PFBody *ground pf_add_body(world); pf_set_shape_aabb(ground, -20.0f, -1.0f, 20.0f, 0.0f); pf_set_static(ground, 1); for (int i 0; i 120; i) { pf_step(world, 1.0f / 60.0f); float y pf_get_position_y(ball); printf(frame %d: ball y %f\n, i, y); } pf_destroy_world(world); return 0; }这个流程包含四步创建世界、添加刚体、逐帧调用pf_step、销毁世界。你只需要把注意力放在pf_step的参数上。这一步传入的是固定时间步长一般用1.0f / 60.0f表示每次模拟 1/60 秒的物理变化。3.3 判断一次物理更新是否正常的标准运行程序后你可以观察输出。正常现象是球的 y 坐标从 10 开始逐渐减小触碰地面后开始反弹反弹高度逐渐降低最终贴近地面并保持稳定。如果出现以下现象需要排查数值变成nan或inf通常是积分步长过大或者碰撞响应里产生了过大的速度。球直接穿过地面说明碰撞检测没有生效或者球速度过快、时间步长过大。球在地面附近抖动说明碰撞响应和重力之间没有收敛可能是迭代次数不足或恢复系数设置过大。这里最值得先做的是跑 10 万帧确认物理状态不会越来越糟。如果不稳定哪怕 Demo 看起来正常也不能放到 ROM 里。运行 10 万帧的目的不是验证速度而是验证稳定性和确定性。物理引擎在长时间运行后如果出现漂移或爆炸说明求解器参数或积分方式有问题。4. 核心参数和调优顺序4.1 固定时间步长是第一步物理模拟最忌讳的是每帧用不固定的时间差。游戏帧率在旧平台上经常波动有时 30 帧有时 20 帧如果你直接把每帧的间隔时间传给物理引擎物体运动会变得不稳定。正确做法是使用累积器double accumulator 0.0; const double dt 1.0 / 60.0; uint64_t last_time get_time_ms(); while (game_running) { uint64_t now get_time_ms(); double frame_time (now - last_time) / 1000.0; last_time now; if (frame_time 0.25) { frame_time 0.25; // 防止长时间停顿后一次性补太多帧 } accumulator frame_time; while (accumulator dt) { pf_step(world, dt); accumulator - dt; } }这个模式看到很多引擎在用。它保证物理始终以固定步长更新渲染帧率不会直接影响物理稳定性。补帧上限也要设否则窗口拖拽或调试暂停后物理会一次性补几百帧把模拟搞崩。4.2 迭代次数、摩擦和恢复系数单文件物理引擎一般会用迭代求解器来处理碰撞。迭代次数决定碰撞后物体之间的“分离速度”。迭代次数越高穿透越小但 CPU 开销越大。在旧平台上默认迭代次数可能只有 1 到 4 次已经可以用。如果物体堆叠时明显抖动可以尝试增加到 6 或 8 次。摩擦系数和恢复系数需要按游戏手感调摩擦系数 0 表示完全光滑1 表示非常粗糙。恢复系数 0 表示完全无弹跳1 表示完全弹性。大于 1 的恢复系数会引起能量增加使用后物体可能越弹越高最终爆炸。调参顺序建议是先固定恢复系数为 0确认碰撞能稳定分离再逐步增加摩擦看物体滑动是否合理最后调弹跳。这个方法能避免多个参数相互干扰时找不到问题根源。4.3 浮点和定点数的选择N64 有浮点协处理器Dreamcast 的 SH-4 也支持浮点PSX 则比较尴尬。PSX 的 CPU 浮点性能并不强很多 PSX 自制开发者会使用定点数或者直接用整数模拟位置计算。如果你要移植到 PSX先确认 Picophysics 是否使用浮点以及它对浮点性能的依赖有多大。如果只是在水平和垂直方向做简单物理可以使用定点数。基本做法是把位置、速度用整数表示单位是 1/256 或 1/1024 像素每帧更新时用固定小数乘法处理。这里没有统一标准需要根据目标平台和游戏类型选择。不过有一个通用原则如果库本身是浮点实现先不要急着改成定点等游戏逻辑稳定后再优化。很多物理不稳定问题不是定点浮点引起的而是时间步长、迭代次数、对象数量三个因素没配合好。下面给一个简单的参数对比参考参数入门推荐值进阶调整方向判断标准固定时间步长1/60 秒1/30 秒或 1/120 秒高速物体是否穿墙迭代次数2 到 46 到 8堆叠物体是否抖动恢复系数0.2 到 0.50 到 1是否越弹越高摩擦系数0.30 到 1滑动是否自然最大对象数32按内存和 CPU 实测调整帧率是否稳定5. 移植到 N64、PSX、Dreamcast 的差异5.1 平台工具链和内存差异三个平台的编译方式完全不同。N64 自制开发常用 libdragon 或 libultra。libdragon 的优点是工具链较新内存管理和文件接口贴近现代 C 习惯可以把单文件物理库直接编译进去。但要注意libdragon 项目默认使用静态内存分配物理库如果使用malloc需要确认 SDK 是否提供堆管理。PSX 常用野火 SDK 或 PsyQ。这些工具链比较老对 C 标准支持有限代码里不能随便用 C99 的新语法。单文件库如果依赖stdint.h或某些内建函数可能会遇到问题需要提前查看头文件兼容性。Dreamcast 用 KallistiOS工具链是基于 GCC 的sh-elf交叉编译器整体最接近现代开发环境。Dreamcast 内存 16MB运行单文件物理引擎通常没有压力你可以把更多精力放在图形和渲染上。项目N64PSXDreamcastCPUMIPS 系列MIPS R3000 系列SH-4常见内存规模4MB 到 8MB2MB 左右16MB常见 SDKlibdragon / libultra野火 SDK / PsyQKallistiOS浮点支持有 FPU偏弱支持C 标准兼容性较新工具链可用较老较新5.2 缓存、字节序、指令集和栈MIPS 和 SH-4 都是 RISC 架构访问未对齐的内存时可能产生异常。物理对象结构体里如果有大量浮点数组需要注意结构体对齐避免跨平台移植后出现随机崩溃。字节序问题也很现实。N64 的 MIPS 是大端PSX 的 MIPS 是小端Dreamcast 的 SH-4 是小端。如果你的物理引擎会把对象数据序列化到存档文件或者通过通信接口传递字节序处理必须统一。否则 PC 端构建的存档放到 N64 上位置数据全部是颠倒的。还有一个容易忽略的点是栈空间。旧平台可用的栈通常很小递归调用要避免。物理引擎如果使用递归遍历碰撞树在栈小的平台上很容易触发溢出。建议用迭代方式替代或者把递归深度控制住。5.3 从模拟器到真机的测试顺序我的习惯顺序是先 PC 命令行测试再模拟器测试最后真机测试。模拟器速度慢但调试方便能看日志能打断点能检查内存。真机测试暴露的是时序、缓存、硬件差异问题比如有的 N64 模拟器没有正确模拟 RSP 的浮点行为导致物理结果和真机不同。如果你先在模拟器上跑 10 万帧没有问题再上真机跑 5 分钟游戏流程记录是否出现异常抖动、卡死、穿模。真机上的帧率变化、中断频率、控制器输入时机都会影响物理表现。尤其是 N64 和 PSX它们的视频输出和内存控制器行为比模拟器更保守有时模拟器能跑通真机就是不行。6. 常见问题排查顺序6.1 构建失败先查工具链和 C 标准单文件物理库最常出现的问题是编译错误。比如变量声明在for循环内部C89 编译器不支持比如用了//行注释旧编译器可能不认比如缺少#include string.h但在某些 SDK 里没有默认包含。遇到构建失败先看两个地方工具链版本。如果你用的是老 SDK优先确认库是否兼容 C89。源文件编码。某些 Windows 编辑器会保存成带 BOM 的 UTF-8交叉编译器可能报错。不要在编译错的时候急着改物理库。先写一个空文件只#include物理头文件编一次。如果空文件都编不过问题在工具链不在库。6.2 物理抖动先查时间步和迭代物体抖动是最常见的物理 bug。出现抖动时先确认传入pf_step的时间步长是不是固定值。如果时间步长不固定物理能量会不断变化表现就是物体在地面附近高频震动。时间步长正常之后再看迭代次数。迭代次数太低物体堆叠时接触点多约束无法在一步内全部求解会产生“弹跳感”和“颤抖感”。这种情况可以增加迭代次数但由于旧平台 CPU 有限我更推荐减少同屏堆叠物体数量。6.3 对象穿透和内存异常该怎么查对象穿透通常有两种原因。一是时间步长过大物体速度太快一个物理步内穿过了整个碰撞体。解决方法是缩小固定时间步长比如从 1/60 改成 1/120或者开启连续碰撞检测。二是碰撞检测只处理了形状的重叠没有处理高速相对运动。单文件库一般不会做 CCD所以如果游戏里有高速子弹建议自己用射线检测补充。内存异常表现为花屏、随机卡死、对象数据莫名其妙被修改。先检查物理对象数组是否越界。很多单文件库用固定数组存储对象删除时如果只是标记删除没有真正减少计数最终会导致数组写满。你可以把对象数量打印出来看看是不是在持续增长。如果对象数据被其他模块覆盖优先检查物理世界的结构体大小以及你在工程里是否重复定义了同一个宏。这种问题往往不是物理库的问题而是工程文件中多个模块之间有命名冲突。遇到一次随机崩溃不要急着改物理算法。先开日志把每帧对象数量、位置、速度、内存占用打印出来。很多时候崩溃发生在物理模块内部但真正原因是其他模块写坏了内存。7. 落地经验什么值得留意7.1 单文件物理在工程里的定位如果把游戏工程比作一辆车单文件物理引擎更像是一个“可以直接改的底盘”而不是“自动巡航系统”。它给你基本物理能力但你需要根据目标平台做裁剪和加固。我的建议是把单文件物理库当作一个独立模块尽量不直接和游戏逻辑耦合。你可以在它外面封装一层“物理世界接口”比如create_game_world、spawn_ball、check_hit。这样以后如果发现库不够用可以替换成更复杂的引擎不需要改动游戏主体。7.2 把物理模块封装成独立接口封装的好处有三个方便调试。你可以在接口层记录所有物理对象的输入输出。方便替换。换物理库时只需重写封装层。方便测试。可以单独跑物理测试用例不依赖渲染、输入、音频模块。一个比较简单的封装结构是struct game_physics { struct PFWorld *world; int next_id; struct game_object objects[MAX_OBJECTS]; }; void game_physics_init(struct game_physics *gp); int game_physics_add_ball(struct game_physics *gp, float x, float y, float r); void game_physics_update(struct game_physics *gp, float dt);这里的示例命名只是说明分层思路实际情况以你项目风格为准。7.3 复古平台之外的价值这类单文件物理方案不只对复古平台有用。在 Web 开发、嵌入式开发、小型游戏机上同样适用。只要你面对的环境内存小、编译器老、依赖少单文件物理库都是一个很好的起点。它能让你用最少的成本先把游戏玩法验证起来。但也要再次强调不要因为“单文件”就误以为它是万能库。功能边界、参数调整、跨平台测试仍然要自己完成。真正落地时最该盯住的不是功能列表而是输入格式、资源占用和失败重试。物理引擎在每个平台上的确定性、内存布局和碰撞回调才是决定你能不能顺利发布的关键。我个人的建议是先把 PC 命令行 Demo 跑稳再放进模拟器跑 10 万帧最后才考虑移植到真实硬件。很多问题不是物理库能力不够而是前置环境和输入材料没有处理干净。等你把这些都理顺了再决定是否在游戏里开放给玩家使用就会踏实很多。