先讲一个具体场景：你在开发一款面向 N64 或 PSX 风格的游戏，目标平台不是 PC 模拟器，而是实机或者准实机环境。美术、关卡、角色动画都推进得不错，但一到“物理”这块就卡住了。不是不会写物理，而是你很清楚，现代引擎里那一套完整物理系统根本搬不进去。Box2D 的 float 精度、Heap 分配、动态数组、连续碰撞检测，随便挑一样在老主机上跑起来都很难受。于是你开始找替代方案，然后看到了 Picophysics 这种“single file physics”项目。它看起来是个很小的东西，但真正值得琢磨的不是这个文件有多短，而是它背后代表的一整套思路：在极端资源约束下，如何把物理系统设计成可裁剪、可审查、可移植的状态。
这篇文章想围绕这个项目标题展开，但更想讨论的是它指向的那个问题域——为什么复古平台做物理，难的不是算法，而是资源和工程策略。如果你正准备给 N64、PSX、DC 这类平台写游戏，或者单纯想在低配置环境里搞一个够用的物理系统，这篇文章会很有用。
1. 复古平台做物理，难的不是算法，而是资源预算
很多人一听说“给 N64 写物理引擎”，第一反应是“碰撞检测用 GJK 还是 SAT”“约束求解用 PBD 还是迭代冲量”。但真正到了实机上，最先击垮你的往往不是算法精度，而是资源本身。
1.1 为什么不能把现代物理引擎直接搬过来
现代物理引擎，哪怕是开源的轻量方案，默认假设也和大平台时代完全不同。它们默认你有足够的内存、足够高的 CPU 主频、足够大的缓存、可以随意 new 对象、可以开多线程。但在 N64、PSX、DC 这个代际的主机上，这些假设全部不成立。
以 N64 为例，内存 4MB，加上扩展包也不过 8MB。操作系统、图形资源、音频、关卡数据、角色动画全都要挤在这几 MB 里。物理系统如果每帧产生几十个临时对象，内存会迅速失控。PSX 是定点数 CPU，没有硬件浮点单元，而 DC 的浮点能力相对好一些，但内存带宽和 CPU 主频也远不能和今天的硬件比。
更重要的是，现代引擎的物理模块往往不是一个人能完全读懂的。Box2D 的源码有几十个文件，Bullet 更大。即使你只是把源码搬进去，编译时间、代码体积、依赖关系全都会变成新问题。而单文件物理方案的核心价值是：整个物理系统的实现可以放在一个文件里，你可以一口气读完，知道每个函数在哪，知道每个系统依赖什么，知道删掉哪个部分不影响核心功能。这种“可审查性”在资源受限平台上直接对应着“可裁剪性”。
1.2 N64、PSX、DC 各自的算力边界
这三台平台的性能边界不太一样，但共同点是都容不下一个“通用物理引擎”。具体来看：
N64 的 CPU 是 93.75MHz 的 MIPS R4300i，虽然理论上性能不差，但实际开发中 L1 缓存只有 16KB，指令和数据缓存分开，编译器优化不到位时性能会差很多。物理系统的热点循环、碰撞检测候选对、约束求解迭代，全部要想着怎么塞进缓存。
PSX 的情况更特殊。它的 CPU 是 MIPS R3000A 兼容核心，主频 33.87MHz，整数性能尚可，但浮点单元很弱。所以很多 PSX 时代的物理计算都用手写定点数或者查表法来做。三角函数、开方、除法在定点数下要小心处理，不然误差会越来越大。
DC 是三台里比较友好的，CPU 是 200MHz 的 SH-4，带硬件浮点单元，内存有 16MB。但也不是没有代价：SH-4 的浮点指令流水线有特定约束，分支预测能力弱，物理系统里大量 if 分支会带来惩罚。所以 DC 上做物理，往往要考虑分支友好性和内存带宽。
从工程经验看，老平台物理系统的最佳策略不是“一次写个完整引擎”，而是“先确定项目需要哪些物理行为，然后只实现这些行为，并把所有常量、参数、碰撞形状类型、迭代次数全部集中在一个地方方便调整”。
注意：不要一上来就追求“完整物理模拟”。N64、PSX 时代的很多经典游戏，物理上其实非常粗糙——大部分是直线运动加碰撞响应，少数高级游戏才用上真正的刚体动力学。你要做的不是复刻一个物理引擎，而是让玩家感觉到“物理存在”。
2. 单文件真正的意义：可审查、可裁剪、可移植
Picophysics 这个项目标题里最有价值的词，不是 physics，而是 single file。按现在的主流工程习惯，代码要分模块、拆文件、搞目录结构。但在老平台开发里，单文件是一种非常务实的选择。
2.1 单文件不是“代码少”，而是依赖边界清晰
单文件物理引擎并不意味着代码量一定少。一个能处理刚体、碰撞、约束的最小系统，写下来少说也要一两千行。单文件的真正好处是依赖关系变得极其清晰：整个物理模块只有一个 .c 或 .h 文件，它要么只依赖标准库的少数几个函数，要么完全不依赖外部代码。这意味着你可以把它丢进任何一个编译环境，而不需要先搞懂它的构建系统。
对于 N64、PSX、DC 开发来说，这点特别重要。这些平台的工具链非常古老，很多还是基于命令行 makefile 或者特定 IDE。你不可能像在现代 Web 项目里那样方便地引入一个 npm 包或者 CMake 子模块。一个单文件模块，直接拖进工程就能编译，这是巨大的时间节省。
从代码组织角度看，单文件也不是说一个文件里所有东西平铺直叙，而是可以用清晰的分区来组织：
// ============================================ // 1. 配置区：所有可调参数集中在这里 // ============================================ #define PHYS_MAX_BODIES 64 #define PHYS_FIXED_STEP_HZ 60 #define PHYS_POSITION_ITER 3 // ============================================ // 2. 数据类型：向量、刚体、形状、碰撞结果 // ============================================ typedef struct phys_vec2_t { float x, y; } phys_vec2_t; typedef struct phys_body_t { ... } phys_body_t; // ============================================ // 3. 内部工具函数：数学、内存池操作 // ============================================ // ============================================ // 4. 核心模拟：步进、碰撞检测、求解 // ============================================ // ============================================ // 5. 对外接口 // ============================================这种分区方式让单文件不至于变成一团乱麻。你可以在文件内部用明确的注释块隔开不同职责，阅读时按区块浏览，修改时也不怕找不到位置。
2.2 用宏和条件编译管理平台差异
单文件结构下，平台差异怎么处理？答案是用宏和条件编译。比如 N64 上需要把浮点运算换成定点数，PSX 上要避免除法，DC 上要优化分支结构。这些差异可以很好地封装在文件内部：
#ifdef PHYS_PLATFORM_N64 #define PHYS_REAL int32_t #define PHYS_MUL(a, b) fixed_mul(a, b) #elif defined(PHYS_PLATFORM_PSX) #define PHYS_REAL int32_t #define PHYS_DIV(a, b) fixed_div(a, b) #else #define PHYS_REAL float #define PHYS_MUL(a, b) ((a) * (b)) #endif这样写的好处是：游戏逻辑层只看到统一的物理接口，底层实现可以针对不同平台替换。而由于所有条件编译都在一个文件里，你一眼就能看出平台相关的代码有哪些，改起来不会牵一发而动全身。
回到主判断：单文件物理方案真正解决的不是“代码量”问题，而是让物理系统在一个受限环境里变得可控。当你知道整个物理系统只有这一个文件时，你会更愿意去读它、改它、精简它。这种信心在大型多文件项目里反而不容易建立。
3. 最小物理内核怎么搭：从定点数到碰撞求解
如果你打算照着 Picophysics 的方向自己搭一个单文件物理系统，可以按下面这个顺序来。这个顺序不一定是唯一的，但按我实际的经验，它是问题最少的一条路线。
3.1 先定坐标系和数值表示
第一步不是写碰撞检测，而是确定坐标系和数值类型。老平台上有两种常见选择：单精度浮点和定点数。
- 如果目标平台是 DC 或者带硬件浮点的移植平台，直接用 float 就好。SH-4 的浮点能力足够，而且 float 的代码可读性最好。
- 如果目标平台是 N64、PSX 这类浮点较弱的平台，就要考虑定点数。常见做法是使用 16.16 格式，也就是高 16 位表示整数部分，低 16 位表示小数部分。这种格式表示范围够用，乘法和加法可以用普通整数运算完成，只是需要额外处理溢出。
如果你想把定点数和浮点数的切换成本降到最低，抽象一个物理实数类型是关键。在前面提到的PHYS_REAL宏基础上，再封装几个基本运算函数或宏，后续写碰撞检测时就不用关心底层是定点还是浮点。
实际落地时，我建议一开始先用 float 在 PC 上把逻辑跑通，再切换到定点数优化。不要一开始就设定点数，否则调试阶段判断误差来源会非常痛苦。
3.2 固定步长与半隐式欧拉
物理模拟最怕不稳定，而不稳定的根源往往是变步长。现代游戏引擎常用固定时间步长配合插值来解决这个问题。对老平台来说，固定步长还有另一个好处：它让行为可复现。只要输入相同、步长相同，结果就确定。
一个典型的最小物理循环长这样：
const float fixed_dt = 1.0f / 60.0f; float accumulator = 0.0f; float frame_time = get_frame_delta_time(); accumulator += frame_time; while (accumulator >= fixed_dt) { phys_step(fixed_dt); // 内部执行积分、碰撞、求解 accumulator -= fixed_dt; }积分方式建议使用半隐式欧拉。它实现简单，稳定性和能量表现比显式欧拉好得多。具体步骤是：
- 先更新速度：
v += a * dt - 再更新位置：
x += v * dt
顺序不能反。为什么半隐式欧拉比显式更好用？因为先更新速度再更新位置，意味着位置更新用的是“新的速度”，这会让系统在弹簧约束、重力场景下更加稳定，不容易出现能量爆炸。
3.3 碰撞检测的顺序：宽阶段、窄阶段、求解
一个完整的最小物理核心，碰撞检测至少要分两个阶段。即使只有几十个刚体，也不建议直接做两两碰撞检测，因为复杂度是 O(n²)。
宽阶段的目标是快速排除不可能相交的物体。最简单、老平台也足够好用的方案是用空间网格或者简单的 AABB 排序：
for each body A: for each body B where A.id < B.id: if body_pair_aabb_overlap(A, B): narrowphase_collide(A, B);如果你不想维护空间网格，一个更轻量的做法是 sweep and prune。把所有刚体的 AABB 按 x 轴最小值排序，然后只检测重叠区间内的候选对。这个方案在刚体数量几十个、分布比较均匀时效果很好，而且实现只需要几十行代码。
窄阶段则根据形状类型做精确碰撞检测。对复古平台游戏来说，最常用的碰撞形状不是复杂凸多边形，而是：
- AABB：平台跳跃游戏里的地面、墙壁、箱子
- 圆形：角色碰撞、运动物体、翻滚体
- 胶囊体：角色身体，跑跳场景特别好用
- 静态三角网格：地形和关卡碰撞
胶囊体比矩形更适合做角色碰撞，因为它的边缘是圆的，在斜坡和台阶边缘不容易卡住。实现也不复杂：把线段与圆的距离检测做对，再处理两端半球就行。
最后一步是约束求解。这里用简单迭代冲量就够了，不需要上 PBD 或 LCP 求解器。每次步进里跑 3 到 5 次迭代，每次迭代里把所有碰撞点的速度修正一遍：
for (int iter = 0; iter < PHYS_POSITION_ITER; iter++) { for (int i = 0; i < contact_count; i++) { solve_contact_impulse(&contacts[i], dt); } }为什么 3 到 5 次迭代就够？因为复古游戏里的物理系统通常不需要堆叠大量刚体。角色踩在箱子上、踢飞一个小物体、门和机关的运动，这些场景下 3 次迭代肉眼已经看不出来问题。真正需要 10 次以上迭代的场景是几百个箱子堆叠，那在老主机上本来就不现实。
4. 性能预算与优化优先级
在 PC 上写物理引擎，性能优化通常是最后一步。但在老平台上，性能必须在设计阶段就进入考量。一个常见的错误是先写一个“功能完整”的物理引擎，再开始优化，结果发现优化无从下手。
4.1 算力优先：先砍候选对和迭代次数
从算力角度看，物理系统的消耗主要集中在两个部分：碰撞检测和约束求解。碰撞检测里，宽阶段和窄阶段的比例大概随场景变化；约束求解则跟接触点数量和迭代次数线性相关。
一个实用的优化思考顺序是这样的：
- 减少参与模拟的刚体数量。静态物体不进活动列表，只参与碰撞检测，不参与积分。
- 减少候选对。空间网格或排序法可以把 O(n²) 降下来，这是收益最大的优化。
- 减少窄阶段的计算。用“先 AABB 再精确形状”的两步检测，避免所有物体都直接做精确碰撞。
- 减少迭代次数。在视觉效果接受范围内，把迭代次数从 8 降到 4 或 3。
- 减少每帧步进次数。如果项目可以用 30Hz 物理步长，就不必跑 60Hz。尤其是平台跳跃类游戏，30Hz 配合插值渲染效果仍然不错。
不要反过来，先搞什么向量化、指令集优化。在老平台开发里，算法层级的裁剪通常比微优化收益大得多。
4.2 内存优先：静态数组是底线
老平台最忌讳动态内存分配。物理系统每一帧产生临时对象、每次动态扩容、每次释放内存，都可能引发不可预测的性能抖动和内存碎片。
单文件物理方案通常会约定：所有刚体、碰撞形状、接触点都存放在预先分配的数组中。这意味着最大刚体数量、最大接触点数量必须在编译期确定：
typedef struct phys_world_t { phys_body_t bodies[PHYS_MAX_BODIES]; int body_count; phys_contact_t contacts[PHYS_MAX_CONTACTS]; int contact_count; } phys_world_t;这种静态分配方式有两个好处：一是内存使用量完全可预测，二是物理系统不会因为内存分配失败而突然崩溃。代价是最大数量被固定，但这对复古平台游戏来说完全可接受。你只需要在项目开始时估算好场景里最多会出现多少个动态物体，然后给上限留出余量。
如果必须处理动态数量，用内存池而不是 malloc。一块预分配的大缓冲区，把空闲节点串成链表，分配和释放都是 O(1)，而且不会产生碎片。这个技巧在单文件物理引擎里非常实用。
4.3 不同平台的参数策略
即使同一个物理引擎，在 N64、PSX、DC 上的参数也应该不一样。物理步长、最大刚体数、迭代次数都要按平台性能调整。
| 平台 | 参考主频 | 内存 | 建议物理步长 | 建议活动刚体数 | 建议迭代次数 | 说明 |
|---|---|---|---|---|---|---|
| N64 | 93.75 MHz | 4-8 MB | 30 Hz 或 60 Hz | 24-48 | 3 | 注意缓存友好性，热点数据尽量连续 |
| PSX | 33.87 MHz | 2-4 MB | 30 Hz | 16-32 | 3 | 避免浮点，手写定点数，除法用查表 |
| DC | 200 MHz | 16 MB | 60 Hz | 48-96 | 4-5 | 可以用浮点，但注意分支预测 |
这些数值不是硬件限制的准确数据，更接近一种工程经验估计。实际项目要以你的场景复杂度为准，先用一组保守参数跑起来，再一点点往上调。如果画面出现穿透或抖动，优先检查是不是迭代次数不够，而不是立刻上连续碰撞检测。
注意：在 N64 和 PSX 上，建议不要把物理步长设成 60Hz。理由很简单：你的 CPU 还要负担渲染、音频、游戏逻辑。物理跑 60Hz 会让 CPU 占用瞬间拉满。30Hz 物理配合渲染插值，在平台跳跃游戏里视觉上几乎无法察觉差异。
5. 老主机上怎么调试物理
这是单文件物理方案另一个特别值钱的地方：因为它小，所以调试起来反而可控。但老主机的调试手段和现代完全不一样，没有断点调试器，没有 profiler，很多时候甚至没有输出设备。所以调试策略也要重新设计。
5.1 没有断点调试器时的排查链路
我一般把老平台物理问题排查分成四层，按这个顺序来定位：输入层、单步层、数值层、交互层。
第一步，看输入。物理系统是否正确收到了角色控制参数、重力、初始速度？方向有没有反？数值是不是超出了预期范围？很多“物理诡异”的问题，最后查出来是输入错误。
第二步，看单步。在 PC 上用同一套代码、同一个输入序列，把每帧位置、速度、碰撞点打印出来，看是哪一步开始出现异常。是积分的问题、碰撞检测的问题，还是求解的问题？这一层是排查主战场。
第三步，看数值。如果单步逻辑看起来没问题但结果不对，就要检查数值表示是否溢出。定点数尤其要注意乘法后是否超过 32 位范围。比如两个 16.16 格式的数相乘，结果要右移 16 位才能回到定点数格式，这个过程中间值会超过 32 位，需要用中间 64 位或者调整精度。
第四步，看交互。物理系统只有在跟其他系统交互时才出问题？比如角色跟移动平台、传送带、旋转门互动的场景。这时问题很可能不在物理核心，而在物理系统外部——比如你移动了碰撞体但没有同步到宽阶段的数据结构。
5.2 让物理结果可复现
老主机调试很难，所以“可复现”比任何调试器都重要。固定时间步长是实现可复现的前提。如果每帧步进次数不确定，同样的操作在两次运行时物理结果就会漂移。
在单文件物理系统里，建议从一开始就把随机种子、外部输入、步进次数全部纳入“可复现管线”。需要复现问题时，只要记录初始状态和输入序列，就能精确重放整个物理过程。
实际项目中，我会在 PC 端写一个 headless 测试程序，不渲染，不跑音频，只跑物理步进，把每个刚体的位置和速度输出到 CSV 文件。然后在老主机上跑同样的场景，也输出同样的数据，两个文件一对比，差异立现。这个方案成本低，效率却很高。
6. 什么场景适合这个方案，什么场景应该绕开
单文件物理方案不是万能解。它在复古平台开发里非常好用，但也有明确的适用边界。搞清楚了边界，你才不会在错误的方向上浪费大量时间。
6.1 适合：平台跳跃、解谜、轻量 3D 场景
如果你的游戏属于下面几类，单文件物理引擎会很合适：
- 2D 平台跳跃。大量地面、墙体、箱子的 AABB 碰撞，少量角色与机关的交互，重力、跳跃、平台移动、传送带，这些需求只需要几十个刚体和很简单的求解器。
- 2.5D 探险游戏。角色在 3D 场景里沿固定平面移动，碰撞以圆形或胶囊体为主，物理关注点在于角色与关卡的交互，而不是多个物体之间的复杂堆叠。
- 轻量 3D 解谜或动作游戏。一个房间里只有几十个动态物体、一些触发器、几个可推动的箱子，不需要大规模角色群体物理。
这类场景的共同特征是：动态物体数量少、物体之间的约束关系简单、物理行为以运动学和简单碰撞响应为主。物理系统作为一个模块嵌在游戏主循环里，不承担大量 AI 模拟或角色控制任务。
6.2 不适合：大规模角色物理、精确物理模拟
反过来，以下场景不建议用单文件物理方案硬扛：
大规模角色群体物理，比如成群结队的小兵碰撞，或者几百个碎片弹跳。这种场景对碰撞检测和求解的压力远超单文件方案能承受的范围。更适合的做法是简化成粒子系统，或者用空间散列加简化碰撞形状专门实现。
需要物理引擎精确性的场景，比如物理拼图游戏要求物体只能放在精确位置，或者机械结构需要多个约束同时满足。这时单文件方案里那几次迭代往往不够用，追求精度就会拖垮性能。
跨平台大规模复用的场景。如果你同一套物理要用在 PC、主机、移动端，还要支持各种高级功能，那还是选一个成熟引擎更合适。单文件方案对维护者的物理知识要求很高——你自己就是唯一的文档和维护者。
把话说回来。如果你决定走“给复古平台写一个单文件物理”这条路，最好的做法不是直接抄别人的代码，而是先明确自己的最小场景——最复杂的关卡里有多少物体、需要哪些碰撞形状、物理互动有多少个种类，然后按这个去实现一个精简但完整的系统。Picophysics 这样的项目至少给了我们一个很好的起点判断：在 N64、PSX、DC 这个量级的平台上，物理系统完全可以是单文件，可以是可控的，可以被一个开发者完全理解。这件事放在今天的开发环境里有点反常规，但恰恰是复古平台开发的乐趣所在——你不得不真正理解每一行代码的作用，而不是把复杂度交给引擎。
