 PC 架构的演进)
很多人以为体素是《DOOM》2.5D 游戏的后续升级但反直觉的是体素其实是《DOOM》的学长本文从现代统一内存架构UMA的视角出发硬核拆解 1998 年《三角洲部队》失落的 CPU 纯软件体素渲染算法。文章通过完备的 C 语言源码与原理分析深度解密早期 3D 游戏是如何在没有 SSE 指令集的时代用 MMX 整数优化对抗“总线之墙”并以此反衬出 N64 与现代 UMA “零拷贝”设计的跨时代远见在《半条命》用多边形骨骼动画把总线逼入绝境之前1998年的 PC 阵营中还横亘着另一尊图形巨兽。它冷酷地拒绝了所有三角形多边形也蔑视一切硬件加速。它选择用纯粹的 CPU 整数算力在内存里生生啃出了一片无边无际的荒野远景。这便是 《三角洲部队》Delta Force 以及它背后那个失落的图形神话——体素Voxel Space引擎。如果说多边形路线是在用复杂的数学公式构建世界的“空心骨架”那么体素则是直接用最原始的像素网格堆砌出世界的“沉重肉身”。在这个奇特的世界里没有 3D 矢量的坐标概念。大自然的山川、沙丘与弹坑被极致地压缩进了一个只有一维高度的数字矩阵中行列表达 X 与 Y内存里填写的数值则隐含着高度 Z。这种用大地的基因去缝合 3D 空间的软件暴力美学让当时的 PC 玩家在不需要任何 3D 显卡的前提下第一次领略到了八百米开外的狙击视距。但这种跨越时代的“细腻”本质上却是一场对系统内存和总线带宽近乎自杀式的暴力压榨。它虽然用精妙的隐式空间映射绕过了多边形几何计算却将 PC 架构推向了另一个更惨烈的深渊——全屏像素的总线大搬迁。现在让我们把时钟拨回 1998 年剥开这具由像素积木堆砌而成的体素肉身看看当时的开发者是如何在没有 SSE 指令集的黑暗时代用算法在总线的刀尖上跳舞的。体素动画的原理首先在《三角洲部队》所使用的 Voxel Space 引擎中地形和物体的渲染本质上并不是计算复杂的 3D 矩阵而是利用 “高度图 颜色图” 进行逐列Column-by-Column的屏幕射线投影。为了在当时的 486 或 Pentium II 处理器上实现丝滑的体素场景“动起来”比如山峦在玩家移动时产生透视位移或者像波浪一样起伏代码必须完全使用整数和定点数Fixed-point来模拟彻底避开昂贵的浮点运算 。体素动画绝对不是 3D 矢量顶点但也不是光栅图形它的原理很特殊即隐式空间映射Implicit Mapping在数学上它有一个对应的物理坐标计算公式如下物理空间坐标 (X,Y,Z)(列号, 行号, 内存里存的数值)假设我们要表达一个 (X2, Y1) 位置上高度为 15 的山头在一个 4 x 4 大小的地图数组里它的物理内存是一条连续的长带下面是具体的数据内存地址: [0] [1] [2] [3] | [4] [5] [6] [7] | [8] [9] ... 二维行列: (0,0)(1,0)(2,0)(3,0)|(0,1)(1,1)(2,1)(3,1)|(0,2)(1,2) ... 实际数值: 0 0 0 0 | 0 0 15 0 | 0 0 ... └──── 行 Y0 ────┘ └──── 行 Y1 ────┘ └──── 行 Y2 ─── ▲ 这就是 (X2, Y1, Z15) 的体素点在体素Voxel Space地形渲染中二维数组矩阵的行索引Row Index代表 Y 轴坐标列索引Column Index代表 X 轴坐标而在这个交叉格子内存里填写的具体数值Value则是 Z 轴高度值。你可以脑补一下它其实很像是个3D的地形地貌图只不过被做成了人体轮廓或者其他的物体形态如下图所示。隐式空间映射”的本质利用内存行列直接作为 X、Y 坐标直接读取标量高度作为 Z 轴非传统三角形矢量渲染。但在这种架构存在一个致命的逻辑闭环它直接导致了 PC 游戏在一段时间内卡在性能瓶颈上无法只修改一个点因为 X 和 Y 绑定在内存网格上如果玩家在游戏里移动整个视野的网格就发生偏转。CPU 无法像现代显卡那样只发一个“旋转矩阵”它必须用复杂的内嵌循环把这张长带内存里的数据重新过滤一遍算出一张全新的屏幕像素表Framebuffer。带宽的绝望算完之后CPU 还要把这张 100% 填满像素的图跨越 PCI 总线硬推给显卡。这本质上是用 CPU 宝贵的算力在内存里做高频的行列索引置换最后去撑爆总线。下面这个例子让我们看清楚体素的数据和OPENGL处理的3D顶点数据之间有何区别// // 1. 真正的【3D 矢量顶点】OpenGL 模式 // struct Vertex3D { float x, y, z; // 每个点都是显式定义的 3D 空间坐标矢量 }; // 描述 2 个山头需要明确写出它们在空间中的绝对坐标 struct Vertex3D mount_vertices[2] { {10.0f, 5.0f, 150.0f}, // 点A {200.0f, 5.0f, 300.0f} // 点B }; // // 2. 连续的【体素高度标量】三角洲部队模式 // // 描述同样的一片空间它不需要记录 X 和 Y因为内存格子本身就是 X 和 Y unsigned char voxel_height_map[] { 0, 0, 0, 150, 0, 0, // 第0行第3个格子的物理位置隐含为 (X3, Y0)高度150 0, 0, 0, 0, 300, 0 // 第1行第4个格子的物理位置隐含为 (X4, Y1)高度300 };这导致了一些概念上的区别OpenGL 的动画矩阵变换旋转指针在 OpenGL 里要让一个三角形转起来你不需要去修改那个 float 数组里的数字。数组保持静止你只需要修改一个叫 Model Matrix模型矩阵 的变量。显卡硬件会自动在渲染时把数组里的每一个点乘以这个矩阵。特点数据在显存里不动计算全在着色器硬件内部。体素动画的原理动态搅动内存重写数组 / 采样偏移要让体素地形或物体“动起来”比如山崩、爆炸形成的弹坑、水面波浪开发者有两种做法直接物理重写用 CPU 每一帧去修改height_map数组里某个方位的值把高度由 15 改成 0代表被炸平了。采样查找表偏移如我们前面代码中的animation_offset在读取数组时根据时间帧对数组的索引进行数学扰动让 CPU 读出错误的“变动高度”在屏幕上产生波浪式的形变。特点每一帧都在疯狂地进行内存寻址与写操作。为了把体素渲染的底层逻辑彻底剥开我写了一段最核心的渲染算法代码。在接下来的剖析中我将试图带你看清它在内存和像素矩阵里‘升维’的精髓。如果你完全看不懂里面的嵌套循环请不必有任何心理负担。因为这是一项早已被扫进历史尘埃的过时技术在它的代码深处流动着的是那个时代由于硬件无能而不得不付出的、极其惨烈且毫无意义的 CPU 算力空转。#include stdio.h #include string.h #include stdlib.h // 引入 abs 用于安全取模 #define SCREEN_WIDTH 320 #define SCREEN_HEIGHT 240 #define MAP_SIZE 1024 // 1024x1024 的高精度体素地图 #define MAP_MASK (MAP_SIZE - 1) // 用于快速位运算取模1023 // 模拟帧缓存存在于系统 RAM 中计算完后一次性倾倒给显卡 unsigned char framebuffer[SCREEN_WIDTH * SCREEN_HEIGHT]; // 静态地图数据高度图与颜色图 unsigned char height_map[MAP_SIZE * MAP_SIZE]; unsigned char color_map[MAP_SIZE * MAP_SIZE]; /** * 体素地形动画渲染核心 * param player_x 玩家当前的定点数 X 坐标 (16.16 格式) * param player_y 玩家当前的定点数 Y 坐标 (16.16 格式) * param horizon 地平线在屏幕上的垂直位置 * param time_frame 时间帧用于让地形产生动态动画如波浪、地震 */ void render_voxel_landscape(int player_x, int player_y, int horizon, int time_frame) { // 每次渲染清空屏幕填满黑色 memset(framebuffer, 0, sizeof(framebuffer)); // 核心思想从左到右对屏幕的每一“列”进行射线投射 for (int x 0; x SCREEN_WIDTH; x) { // 遮挡缓存Y-Buffer从屏幕最底部240开始往上画 // 保证近处的体素画完后远处的体素不会产生无效的重复遮挡渲染 (Overdraw) int hidden_y SCREEN_HEIGHT; // 射线从近处向远处步进 (Z 轴) // 90年代初的核心魔法越远步进越长近处精细远处模糊极大节省算力 for (int z 1; z 400; z (z 50 ? 1 : 2)) { // 1. 简单的透视投影坐标映射定点数运算 // 漏洞修复修复了原有的移位截断与负数取模越界问题 int map_x ((player_x (x - SCREEN_WIDTH / 2) * (z 16)) 16); int map_y ((player_y (z 16)) 16); // 使用位掩码进行安全且高效的环绕取模 map_x MAP_MASK; map_y MAP_MASK; int map_index map_y * MAP_SIZE map_x; // 2. 读取该位置原始的体素高度 int voxel_height height_map[map_index]; // 3. 【体素动画核心】让体素高度随时间产生波动 int animation_offset ((map_x ^ map_y) time_frame) 15; voxel_height animation_offset; // 让地形产生动态位移 // 4. 计算透视缩放后的屏幕高度 屏幕Y (实际高度 - 玩家视角高度) / 距离 地平线 int screen_y ((120 - voxel_height) * 256) / z horizon; // 漏洞修复上下边界双向防御防止内存越界写入 if (screen_y 0) screen_y 0; if (screen_y SCREEN_HEIGHT) screen_y SCREEN_HEIGHT - 1; // 5. 渲染列Column Drawing如果当前体素高出了之前的遮挡线则画出来 if (screen_y hidden_y) { unsigned char color color_map[map_index]; // 垂直填色将这个体素点从上一次的遮挡位置一直向下涂抹到当前位置 for (int y screen_y; y hidden_y; y) { framebuffer[y * SCREEN_WIDTH x] color; } // 更新遮挡缓存后面更远的体素如果比这个矮就直接被剔除 hidden_y screen_y; } } } }分析上面的代码你会发现当 render_voxel_landscape 函数执行完毕后主内存里就躺着一块完整的、大小为 320 * 240 76.8 KB 的画面数据。这时候系统必须调用系统的中断或者驱动接口发起一次 DMA 传输通过总线把这 76.8 KB 的数据硬生生推到显卡显存的物理地址里。但如果把分辨率从320x240提升到640x480最外层的循环翻倍内层的填色数据量直接暴增 4倍达到约 300KB。奔腾 II 处理器在进行这种大规模的“系统内存到显存”的跨区搬运时总线带宽会直接被榨干帧率立刻从 30 帧跌到个位数。并且在这段代码执行时显卡上的 GPU 核心完全在闲置。CPU 里的寄存器或 MMX 寄存器正在为了执行那个 for (int y screen_y; y hidden_y; y) 循环而疯狂空转把颜色值一个字节一个字节地塞进内存里的 framebuffer 数组。注意看到代码里的 MAP_MASK和 16了吗这就是为什么当年的游戏不需要繁琐的if-else逻辑去判断玩家是否走出了地图边界也不需要昂贵的浮点单元。我们利用二进制的溢出环绕特性用一个极简的位元操作就完成了对 1024 空间的死锁。这就是属于 1998 年的硬核性能美学。体素动画的历史从直观的视觉层面上看《三角洲部队》 或更早的 《卡曼奇》 呈现出的画面确实比 《DOOM》 这种 2.5D 多边形游戏要“细腻”得多——它能轻而易举地拉出成千上万个不规则的草丛、连绵的沙丘和弹坑。但如果从性能维度和工程落地来看《DOOM》才是当时工业级的最优解。体素技术之所以在后续的整体性能和商业体验上输给多边形正是因为其背后那个恐怖、不讲道理的算力黑洞。早在 1992 年 11 月NovaLogic 就推出了划时代的直升机模拟游戏 《卡曼奇最大过载》Comanche: Maximum Overkill并首次搭载了第一代 Voxel Space 引擎。而直到整整一年后的 1993 年 12 月id Software 的 《DOOM》 才迟迟降临。一个历史奇观是1992 年的 PC 玩家看着屏幕上由纯 CPU 整数运算堆砌出来的、充满真实颗粒感的体素山脉时其视觉震撼度在某种程度上超越了后来《DOOM》那死板、只有直角直线的迷宫墙壁。在《DOOM》那标志性的“纸片人”大杀四方之前体素其实就已经率先占领了 3D 舞台的中央。然而这尊空有前瞻性算法的体素巨兽却因为不计成本的数据吞吐被精妙折中的 2.5D 多边形算法在帧率上无情吊打。我们需要重新梳理这段极具戏剧性的图形技术史并冷酷地理清在《DOOM》与体素动画艰难走向成熟的这段真空期里行业为了对抗“算力贫瘪”与“总线之墙”究竟夹杂了哪些走入死胡同的怪异技术。两者对比《DOOM》就像是室内大师它的算法极度擅长表达房间、走廊。虽然墙面贴图是方方正正的多边形但在狭窄的室内这种“粗犷”反而带来了极高的清晰度和视觉冲击力。而体素是“户外宅男”他极其擅长画无边无际的荒野。但它致命的缺点是无法在有限的算力下画出带有复杂精细纹理的室内墙壁和 3D 角色。在体素游戏里由于算力全被地形吃光了游戏里的人和房子往往做得比《DOOM》还要简陋、还要像纸片人。至此我们可以总结一下原来现代 OpenGL 往着色器里丢数组是在丢‘数学公式的线索’剩下的全由显卡暴力脑补而当年的体素引擎往函数里投数组是在投‘一具由像素堆砌的沉重肉身。在 PC 分离式架构的泥潭里CPU 频繁翻动这具肉身修改高度数组会引发总线带宽的惨烈窒息但在 UMA 的世界里这种‘原地搅动内存’的暴力却变成了一种近乎免费的图形艺术。【下期预告】 幻影之墙当《半条命》的骨骼动画撞上总线带宽在这一期中我们共同目睹了《三角洲部队》如何用古老的 MMX 指令在内存里暴力揉捏体素在没有显卡加速的荒野里堆砌出大地的肉身却最终在全屏像素的大搬迁中被总线扣押成了个位数的帧率。那么如果不去搬运沉重的像素而是转去拥抱OpenGL与真实的 3D 多边形呢下一期我们将推开 1998 年图形进化的另一扇大门复盘《半条命》Half-Life带来的降维打击。我们将深入解构 Valve 是如何彻底废除死板的“顶点帧动画”引入划时代的骨骼动画Skeletal Animation系统的。看科学家的肢体如何通过几十根虚拟骨骼的旋转在 CPU 的矩阵计算下实时“捏”出如人类般顺滑的动作。但这场主权的移交并非没有代价。你会看到当屏幕上同时出现数十个拥有灵魂的敌人时CPU 实时算出的海量动态顶点是如何将那条带宽捉襟见肘的AGP 总线变成惨烈的绞肉机。你会真正明白什么叫“算得出送不出”的囚徒困境。在这场 PC 阵营为了冲破总线枷锁而走向“堆料与高热”的阵痛前夕我们将正式埋下那颗关于BSP二叉空间分割树的终极种子。大幕已经拉开多边形的白骨即将成形。关注我下一期我们总线墙下见
从现代视角审视统一内存架构（UMA）—— (2) PC 架构的演进
发布时间：2026/5/15 20:48:20
很多人以为体素是《DOOM》2.5D 游戏的后续升级但反直觉的是体素其实是《DOOM》的学长本文从现代统一内存架构UMA的视角出发硬核拆解 1998 年《三角洲部队》失落的 CPU 纯软件体素渲染算法。文章通过完备的 C 语言源码与原理分析深度解密早期 3D 游戏是如何在没有 SSE 指令集的时代用 MMX 整数优化对抗“总线之墙”并以此反衬出 N64 与现代 UMA “零拷贝”设计的跨时代远见在《半条命》用多边形骨骼动画把总线逼入绝境之前1998年的 PC 阵营中还横亘着另一尊图形巨兽。它冷酷地拒绝了所有三角形多边形也蔑视一切硬件加速。它选择用纯粹的 CPU 整数算力在内存里生生啃出了一片无边无际的荒野远景。这便是 《三角洲部队》Delta Force 以及它背后那个失落的图形神话——体素Voxel Space引擎。如果说多边形路线是在用复杂的数学公式构建世界的“空心骨架”那么体素则是直接用最原始的像素网格堆砌出世界的“沉重肉身”。在这个奇特的世界里没有 3D 矢量的坐标概念。大自然的山川、沙丘与弹坑被极致地压缩进了一个只有一维高度的数字矩阵中行列表达 X 与 Y内存里填写的数值则隐含着高度 Z。这种用大地的基因去缝合 3D 空间的软件暴力美学让当时的 PC 玩家在不需要任何 3D 显卡的前提下第一次领略到了八百米开外的狙击视距。但这种跨越时代的“细腻”本质上却是一场对系统内存和总线带宽近乎自杀式的暴力压榨。它虽然用精妙的隐式空间映射绕过了多边形几何计算却将 PC 架构推向了另一个更惨烈的深渊——全屏像素的总线大搬迁。现在让我们把时钟拨回 1998 年剥开这具由像素积木堆砌而成的体素肉身看看当时的开发者是如何在没有 SSE 指令集的黑暗时代用算法在总线的刀尖上跳舞的。体素动画的原理首先在《三角洲部队》所使用的 Voxel Space 引擎中地形和物体的渲染本质上并不是计算复杂的 3D 矩阵而是利用 “高度图 颜色图” 进行逐列Column-by-Column的屏幕射线投影。为了在当时的 486 或 Pentium II 处理器上实现丝滑的体素场景“动起来”比如山峦在玩家移动时产生透视位移或者像波浪一样起伏代码必须完全使用整数和定点数Fixed-point来模拟彻底避开昂贵的浮点运算 。体素动画绝对不是 3D 矢量顶点但也不是光栅图形它的原理很特殊即隐式空间映射Implicit Mapping在数学上它有一个对应的物理坐标计算公式如下物理空间坐标 (X,Y,Z)(列号, 行号, 内存里存的数值)假设我们要表达一个 (X2, Y1) 位置上高度为 15 的山头在一个 4 x 4 大小的地图数组里它的物理内存是一条连续的长带下面是具体的数据内存地址: [0] [1] [2] [3] | [4] [5] [6] [7] | [8] [9] ... 二维行列: (0,0)(1,0)(2,0)(3,0)|(0,1)(1,1)(2,1)(3,1)|(0,2)(1,2) ... 实际数值: 0 0 0 0 | 0 0 15 0 | 0 0 ... └──── 行 Y0 ────┘ └──── 行 Y1 ────┘ └──── 行 Y2 ─── ▲ 这就是 (X2, Y1, Z15) 的体素点在体素Voxel Space地形渲染中二维数组矩阵的行索引Row Index代表 Y 轴坐标列索引Column Index代表 X 轴坐标而在这个交叉格子内存里填写的具体数值Value则是 Z 轴高度值。你可以脑补一下它其实很像是个3D的地形地貌图只不过被做成了人体轮廓或者其他的物体形态如下图所示。隐式空间映射”的本质利用内存行列直接作为 X、Y 坐标直接读取标量高度作为 Z 轴非传统三角形矢量渲染。但在这种架构存在一个致命的逻辑闭环它直接导致了 PC 游戏在一段时间内卡在性能瓶颈上无法只修改一个点因为 X 和 Y 绑定在内存网格上如果玩家在游戏里移动整个视野的网格就发生偏转。CPU 无法像现代显卡那样只发一个“旋转矩阵”它必须用复杂的内嵌循环把这张长带内存里的数据重新过滤一遍算出一张全新的屏幕像素表Framebuffer。带宽的绝望算完之后CPU 还要把这张 100% 填满像素的图跨越 PCI 总线硬推给显卡。这本质上是用 CPU 宝贵的算力在内存里做高频的行列索引置换最后去撑爆总线。下面这个例子让我们看清楚体素的数据和OPENGL处理的3D顶点数据之间有何区别// // 1. 真正的【3D 矢量顶点】OpenGL 模式 // struct Vertex3D { float x, y, z; // 每个点都是显式定义的 3D 空间坐标矢量 }; // 描述 2 个山头需要明确写出它们在空间中的绝对坐标 struct Vertex3D mount_vertices[2] { {10.0f, 5.0f, 150.0f}, // 点A {200.0f, 5.0f, 300.0f} // 点B }; // // 2. 连续的【体素高度标量】三角洲部队模式 // // 描述同样的一片空间它不需要记录 X 和 Y因为内存格子本身就是 X 和 Y unsigned char voxel_height_map[] { 0, 0, 0, 150, 0, 0, // 第0行第3个格子的物理位置隐含为 (X3, Y0)高度150 0, 0, 0, 0, 300, 0 // 第1行第4个格子的物理位置隐含为 (X4, Y1)高度300 };这导致了一些概念上的区别OpenGL 的动画矩阵变换旋转指针在 OpenGL 里要让一个三角形转起来你不需要去修改那个 float 数组里的数字。数组保持静止你只需要修改一个叫 Model Matrix模型矩阵 的变量。显卡硬件会自动在渲染时把数组里的每一个点乘以这个矩阵。特点数据在显存里不动计算全在着色器硬件内部。体素动画的原理动态搅动内存重写数组 / 采样偏移要让体素地形或物体“动起来”比如山崩、爆炸形成的弹坑、水面波浪开发者有两种做法直接物理重写用 CPU 每一帧去修改height_map数组里某个方位的值把高度由 15 改成 0代表被炸平了。采样查找表偏移如我们前面代码中的animation_offset在读取数组时根据时间帧对数组的索引进行数学扰动让 CPU 读出错误的“变动高度”在屏幕上产生波浪式的形变。特点每一帧都在疯狂地进行内存寻址与写操作。为了把体素渲染的底层逻辑彻底剥开我写了一段最核心的渲染算法代码。在接下来的剖析中我将试图带你看清它在内存和像素矩阵里‘升维’的精髓。如果你完全看不懂里面的嵌套循环请不必有任何心理负担。因为这是一项早已被扫进历史尘埃的过时技术在它的代码深处流动着的是那个时代由于硬件无能而不得不付出的、极其惨烈且毫无意义的 CPU 算力空转。#include stdio.h #include string.h #include stdlib.h // 引入 abs 用于安全取模 #define SCREEN_WIDTH 320 #define SCREEN_HEIGHT 240 #define MAP_SIZE 1024 // 1024x1024 的高精度体素地图 #define MAP_MASK (MAP_SIZE - 1) // 用于快速位运算取模1023 // 模拟帧缓存存在于系统 RAM 中计算完后一次性倾倒给显卡 unsigned char framebuffer[SCREEN_WIDTH * SCREEN_HEIGHT]; // 静态地图数据高度图与颜色图 unsigned char height_map[MAP_SIZE * MAP_SIZE]; unsigned char color_map[MAP_SIZE * MAP_SIZE]; /** * 体素地形动画渲染核心 * param player_x 玩家当前的定点数 X 坐标 (16.16 格式) * param player_y 玩家当前的定点数 Y 坐标 (16.16 格式) * param horizon 地平线在屏幕上的垂直位置 * param time_frame 时间帧用于让地形产生动态动画如波浪、地震 */ void render_voxel_landscape(int player_x, int player_y, int horizon, int time_frame) { // 每次渲染清空屏幕填满黑色 memset(framebuffer, 0, sizeof(framebuffer)); // 核心思想从左到右对屏幕的每一“列”进行射线投射 for (int x 0; x SCREEN_WIDTH; x) { // 遮挡缓存Y-Buffer从屏幕最底部240开始往上画 // 保证近处的体素画完后远处的体素不会产生无效的重复遮挡渲染 (Overdraw) int hidden_y SCREEN_HEIGHT; // 射线从近处向远处步进 (Z 轴) // 90年代初的核心魔法越远步进越长近处精细远处模糊极大节省算力 for (int z 1; z 400; z (z 50 ? 1 : 2)) { // 1. 简单的透视投影坐标映射定点数运算 // 漏洞修复修复了原有的移位截断与负数取模越界问题 int map_x ((player_x (x - SCREEN_WIDTH / 2) * (z 16)) 16); int map_y ((player_y (z 16)) 16); // 使用位掩码进行安全且高效的环绕取模 map_x MAP_MASK; map_y MAP_MASK; int map_index map_y * MAP_SIZE map_x; // 2. 读取该位置原始的体素高度 int voxel_height height_map[map_index]; // 3. 【体素动画核心】让体素高度随时间产生波动 int animation_offset ((map_x ^ map_y) time_frame) 15; voxel_height animation_offset; // 让地形产生动态位移 // 4. 计算透视缩放后的屏幕高度 屏幕Y (实际高度 - 玩家视角高度) / 距离 地平线 int screen_y ((120 - voxel_height) * 256) / z horizon; // 漏洞修复上下边界双向防御防止内存越界写入 if (screen_y 0) screen_y 0; if (screen_y SCREEN_HEIGHT) screen_y SCREEN_HEIGHT - 1; // 5. 渲染列Column Drawing如果当前体素高出了之前的遮挡线则画出来 if (screen_y hidden_y) { unsigned char color color_map[map_index]; // 垂直填色将这个体素点从上一次的遮挡位置一直向下涂抹到当前位置 for (int y screen_y; y hidden_y; y) { framebuffer[y * SCREEN_WIDTH x] color; } // 更新遮挡缓存后面更远的体素如果比这个矮就直接被剔除 hidden_y screen_y; } } } }分析上面的代码你会发现当 render_voxel_landscape 函数执行完毕后主内存里就躺着一块完整的、大小为 320 * 240 76.8 KB 的画面数据。这时候系统必须调用系统的中断或者驱动接口发起一次 DMA 传输通过总线把这 76.8 KB 的数据硬生生推到显卡显存的物理地址里。但如果把分辨率从320x240提升到640x480最外层的循环翻倍内层的填色数据量直接暴增 4倍达到约 300KB。奔腾 II 处理器在进行这种大规模的“系统内存到显存”的跨区搬运时总线带宽会直接被榨干帧率立刻从 30 帧跌到个位数。并且在这段代码执行时显卡上的 GPU 核心完全在闲置。CPU 里的寄存器或 MMX 寄存器正在为了执行那个 for (int y screen_y; y hidden_y; y) 循环而疯狂空转把颜色值一个字节一个字节地塞进内存里的 framebuffer 数组。注意看到代码里的 MAP_MASK和 16了吗这就是为什么当年的游戏不需要繁琐的if-else逻辑去判断玩家是否走出了地图边界也不需要昂贵的浮点单元。我们利用二进制的溢出环绕特性用一个极简的位元操作就完成了对 1024 空间的死锁。这就是属于 1998 年的硬核性能美学。体素动画的历史从直观的视觉层面上看《三角洲部队》 或更早的 《卡曼奇》 呈现出的画面确实比 《DOOM》 这种 2.5D 多边形游戏要“细腻”得多——它能轻而易举地拉出成千上万个不规则的草丛、连绵的沙丘和弹坑。但如果从性能维度和工程落地来看《DOOM》才是当时工业级的最优解。体素技术之所以在后续的整体性能和商业体验上输给多边形正是因为其背后那个恐怖、不讲道理的算力黑洞。早在 1992 年 11 月NovaLogic 就推出了划时代的直升机模拟游戏 《卡曼奇最大过载》Comanche: Maximum Overkill并首次搭载了第一代 Voxel Space 引擎。而直到整整一年后的 1993 年 12 月id Software 的 《DOOM》 才迟迟降临。一个历史奇观是1992 年的 PC 玩家看着屏幕上由纯 CPU 整数运算堆砌出来的、充满真实颗粒感的体素山脉时其视觉震撼度在某种程度上超越了后来《DOOM》那死板、只有直角直线的迷宫墙壁。在《DOOM》那标志性的“纸片人”大杀四方之前体素其实就已经率先占领了 3D 舞台的中央。然而这尊空有前瞻性算法的体素巨兽却因为不计成本的数据吞吐被精妙折中的 2.5D 多边形算法在帧率上无情吊打。我们需要重新梳理这段极具戏剧性的图形技术史并冷酷地理清在《DOOM》与体素动画艰难走向成熟的这段真空期里行业为了对抗“算力贫瘪”与“总线之墙”究竟夹杂了哪些走入死胡同的怪异技术。两者对比《DOOM》就像是室内大师它的算法极度擅长表达房间、走廊。虽然墙面贴图是方方正正的多边形但在狭窄的室内这种“粗犷”反而带来了极高的清晰度和视觉冲击力。而体素是“户外宅男”他极其擅长画无边无际的荒野。但它致命的缺点是无法在有限的算力下画出带有复杂精细纹理的室内墙壁和 3D 角色。在体素游戏里由于算力全被地形吃光了游戏里的人和房子往往做得比《DOOM》还要简陋、还要像纸片人。至此我们可以总结一下原来现代 OpenGL 往着色器里丢数组是在丢‘数学公式的线索’剩下的全由显卡暴力脑补而当年的体素引擎往函数里投数组是在投‘一具由像素堆砌的沉重肉身。在 PC 分离式架构的泥潭里CPU 频繁翻动这具肉身修改高度数组会引发总线带宽的惨烈窒息但在 UMA 的世界里这种‘原地搅动内存’的暴力却变成了一种近乎免费的图形艺术。【下期预告】 幻影之墙当《半条命》的骨骼动画撞上总线带宽在这一期中我们共同目睹了《三角洲部队》如何用古老的 MMX 指令在内存里暴力揉捏体素在没有显卡加速的荒野里堆砌出大地的肉身却最终在全屏像素的大搬迁中被总线扣押成了个位数的帧率。那么如果不去搬运沉重的像素而是转去拥抱OpenGL与真实的 3D 多边形呢下一期我们将推开 1998 年图形进化的另一扇大门复盘《半条命》Half-Life带来的降维打击。我们将深入解构 Valve 是如何彻底废除死板的“顶点帧动画”引入划时代的骨骼动画Skeletal Animation系统的。看科学家的肢体如何通过几十根虚拟骨骼的旋转在 CPU 的矩阵计算下实时“捏”出如人类般顺滑的动作。但这场主权的移交并非没有代价。你会看到当屏幕上同时出现数十个拥有灵魂的敌人时CPU 实时算出的海量动态顶点是如何将那条带宽捉襟见肘的AGP 总线变成惨烈的绞肉机。你会真正明白什么叫“算得出送不出”的囚徒困境。在这场 PC 阵营为了冲破总线枷锁而走向“堆料与高热”的阵痛前夕我们将正式埋下那颗关于BSP二叉空间分割树的终极种子。大幕已经拉开多边形的白骨即将成形。关注我下一期我们总线墙下见
