Phoboslab 在 2026 年 5 月 4 日发了一个 Nintendo 64 图形实验。做法很清楚:画面先渲染到 32bit RGBA8888 缓冲区,再让 RSP 把结果钳制并转换成 16bit RGBA5551 帧缓冲显示。

这个实验有意思的地方,不是给 N64 平反一句“它也能做加法混合”。N64 的 RDP 本来就能通过 Color Combiner 配出类似加法混合。麻烦在后半段:结果不 clamp,颜色超过范围会 wrap around,高亮处可能反而变暗、变脏、变色。

所以这件事真正解决的是一个很具体的问题:怎么让 N64 的爆炸、光束、等离子、魔法闪光,更接近 PlayStation 那种“越叠越亮”的效果。

PSX 好用在封顶,N64 难用在回绕

原版 PlayStation 的 GPU 有 src + dst 加法混合。它很适合只增亮的特效:火光叠上去,背景变亮;光束扫过去,亮部更冲。

关键不只是相加,而是 clamp。结果超过颜色上限,就停在最大值。PSX 也是 16bit 色彩,但这条规则让美术和程序都更容易预期结果。

N64 的 RDP 问题在这里反过来。它可以配出类似加法,但混合结果不钳制。超过范围后会回绕到低值。一个本该发白的爆炸边缘,可能变暗;一个本该发亮的能量球,可能出现怪色。

路线怎么混合超出范围后实际效果
PSX GPUsrc + dstclamp 到最大值爆炸、光束更稳定地变亮
N64 RDPColor Combiner 可配类似加法wrap around高亮处可能变暗、变色
Phoboslab 方案先画到 32bit 中间缓冲RSP 转 16bit 时 clamp用额外成本换稳定增亮

这也是很多人觉得 PSX 同世代特效更“亮”的底层原因之一。它不是单纯审美差异,也不是谁的美术一定更强。硬件管线的脾气不同,最后会落到画面上。

32bit 缓冲加 RSP,是补短板,不是开挂

Phoboslab 的方案不绕开 RDP 绘制。RDP 仍然负责画,只是目标换成 32bit RGBA8888 渲染缓冲。

素材和颜色按 1/8 强度绘制。这样做是给多次加法叠加留出 8bit 余量,尽量避免中间阶段先炸掉。最后一步,再由 RSP 把 32bit 缓冲转成 16bit RGBA5551,并完成钳制。

性能差距很直观。CPU 做 320×240 的 RGBA8888 到 RGBA5551 转换,大约要 70ms,基本不可用。优化后的 RSP 版本用 128bit 向量指令一次处理 8 个像素,全帧转换约 3.1ms。

这 3.1ms 只代表转换耗时,不是完整渲染耗时。这里不能偷换概念。

更大的限制在 RDRAM 带宽。32bit 缓冲的读写数据量接近 16bit 的两倍,RDP 绘制会更慢。N64 图形开发本来就常被带宽卡住,这套方案只是把问题换了一个位置。

成本项影响
32bit 中间缓冲占更多内存带宽,RDP 绘制更慢
RSP 转换320×240 约 3.1ms,只是转换时间
CPU 转换约 70ms,实际价值很低
适用范围更适合局部特效,不适合整场景常开

这也是我不太买账“免费修复 N64 加法混合”的说法。能修,但要付账。付的是带宽、缓冲区和 RSP 时间。

开发者该怎么用,接下来该看什么

受影响最大的是 N64 homebrew 开发者,以及想在复古硬件上做更好特效的人。

更现实的用法不是全画面切到 32bit。开发者可以把 Boss 爆炸、武器光束、菜单高光这类局部效果放进 32bit 流水线,再交给 RSP 钳制回 16bit。这样收益集中,成本也更容易控制。

如果是做完整 3D 场景,全程使用这套方案就要谨慎。RDRAM 带宽会很快变成瓶颈。画面亮了,但帧率掉了,账就不一定划算。

接下来最该看的不是“能不能跑”,而是三件具体事:

  • 能不能只让特效层进入 32bit 缓冲,而不是整帧进入。
  • 能不能用更低分辨率渲染特效,再合成回主画面。
  • RSP 转换和其他任务抢时间时,整帧预算还能不能稳住。

原文提到的 Libdragon、RDPQ 和 HailToDodongo 的 RSPL,也说明现代 N64 homebrew 的变化不只在想法上。工具链正在把过去很难碰的 RDP、RSP 细节,变成更容易试错的工程问题。

但边界也要说清。不要把它理解成当年商业游戏普遍没用的一招,也不要说 N64 原本完全不支持加法混合。准确说法是:N64 支持得不顺手,缺少钳制造成实用性受限;现代开发者用 32bit 缓冲和 RSP 转换,补上了这一段。

回到开头那个问题:N64 能不能做亮眼加法混合?能。但它不是一个开关,而是一笔工程账。账算得过,特效就亮;账算不过,亮度会变成帧率和带宽的债。