查看914 KiB的资产看起来好像有很多未使用的DRAM。但您需要记住，428KiB可执行文件也必须与堆栈、运行时变量一起放入其中。运行时实际上只有大约1 MiB的DRAM可用。琐事：深入PSXDOOM-RE源代码，我们发现了一个P_LoadBlock函数，该函数在放弃之前将尝试从CD读取多达4次[14]次。与易刮伤的媒体打交道的乐趣之一。我没想到光碟Seek Time会对游戏的设计产生如此重大的影响。有些游戏，如Crash Bandicoot，是用分页系统从头开始构建的，它们设法在运行时流式传输CD上的内容。在厄运的情况下，发动机做不到这一点。除了一首特别的歌曲(是的，“末日俱乐部”)，游戏期间不会使用这张CD。Id Software的人从来都不喜欢摆在桌面上的容量/速度权衡的CD-ROM。主要的论点有点哲学性。我不喜欢人们对CD游戏的期望。有没有人认为“撞车与燃烧”中的芝士球对话是一个很好的补充？它让我反胃。人们期望CD游戏会有大量的数字化语音和视频，而3DO将与之紧密联系在一起。这里的笑话是，如果我们制作“末日”的CD版，你将得到游戏和一小时的故事片“末日的制造”。公司花费数十万美元将所有这些媒体投入到他们的游戏中，而这实际上往往有损于这一点。我们不想成为这群人中的一员。我宁可把必要的东西删减到可以装在盒式磁带上，也不愿徒劳地放在一张CD上。我对游戏设计有一种极简主义的美感。
琐事：厄运事件是通过绊线触发的。当交叉时，具有特殊属性的行将调用特殊函数。"；旧版引擎没有允许播放歌曲的属性。创建了一个特殊的linedef动作(#142)来触发Club Doom[15]的回放。创建这个级别需要进行如此多的定制，这是令人惊讶的。他们一定很喜欢狂欢。
当我为游戏引擎黑皮书做研究时，我从来没有完全理解设计师哈里·蒂斯利的这句话。这位元老的动画帧数是其他怪物的两倍，而我们在PSX上对他的评价就是不公平。不能失去他的攻击，也不能失去他的复活能力。他太大了，无法包括在内。
事实上，在个人电脑存档DOOM2.WAD中窥视一下，我们可以看到145帧的原始特征。相比之下，IMP有52帧(这在很大程度上要归功于镜像)。尽管很明显CD的650MiB容量不是问题，但不清楚是DRAM还是VRAM是限制因素。从CD-ROM限制的洞察力来看，问题似乎不是将精灵存储在CD上，甚至不是将它们从DRAM提供到VRAM。问题是要把所有东西都保存在DRAM中。琐事：在PSXDOOM-RE的源代码中，完全删除了ArchVile。甚至它的#DEFINE也被注释掉了[16]。#DEFINE CC_ZOMBBY"；#DEFINE CC_SHOUTGUN"；#DEFINE CC_SHOUTGUN"；#DEFINE CC_Heavy"；Heavy Weapon Dude"；。。。#定义CC_HELLE"；地狱骑士"；//#定义CC_ARCH"；ARCH-VILE"；#DEFINE CC_SPIDER"；#DEFINE CC_CYBER"；#DEFINE CC_HERBER"；#DEFINE CC_HERO"；我们的英雄"；
SPU芯片只支持一种格式，即ADPCM。它可以混合多达24个声道(包括CD音轨)，并具有强大的音频处理能力。为了驾驭这头野兽，Doom PSX使用了由音频工程师斯科特·帕特森(Scott Patterson)编写的libWESS(威廉姆斯娱乐音响系统)。该库非常强大，因为它能够复制MIDI系统，在该系统中，重型音符银行(称为声音字体)由轻量级音乐分区引导。它还能够实时操作音频属性，如音量、音调、音符速度和ADSR功能(攻击、衰减、维持和释放)。游戏过程中的所有音乐都是通过libWESS生成的。当然，你会猜到有一个例外，那就是Club doom&34；它是从CD曲目#6播放的。Wess依赖于两种专有的文件格式。有包含音乐和SFX分区的.WMD文件。有PSX VAG(无接头)和包含ADPCM样本的.LCD。当DoOM启动时，libWESS将加载包含在一个名为DOOMSND.WMD的55 KiB小文件中的所有SFX(89)和MUSIC(19)分区。它还会将用于DoomGuy、Doors等的始终使用的ADPCM示例加载到SRAM。加载地图时，libWESS打开MUSIC/MUSLEV%.LCD，其中包含此地图音乐使用的ADPCM样本，以及SNDMAPS%/MAP%%.LCD，其中包含此级别的敌人所需的ADPCM样本。所有的ADPCM样本都直接上传到SRAM，没有
我说过备份所有东西(当时没有源代码控制！)，我们要做一些完全不同的事情。我们最终使用硬件渲染一个像素宽的三角形，就像PC的ASM代码一样，而且效果很好。莫雷斯顿的Playstation方法被证明是在两个轴上镶嵌几何图形，但我总是很满意“末日”给人的感觉不像当时大多数其他Playstation游戏那样摇摆。
多亏了PSXDOOM-RE项目[17]，我们可以看看这是如何做到的。渲染管道被完全重写为两个阶段。后面的部分将详细介绍，但是我们确实可以看到墙渲染函数R_RENDER_WALL发出硬编码1像素宽的绘制命令的位置。Void R_Render_Wall(.。。。){.。整数x1=。。。；//墙的左端。整数x2=。。。；//墙的右端。。而(x1<；x2){。SetRGB0(墙体聚合)；setXY3(墙体聚合，x1，ypos1-1，x1+1，ypos2+1，x1，ypos2+1)；setUV3(墙体聚合，upos，v0，upos，v1，upos，v1)；X1+=1；}}。
琐事：索尼硬件设计师保留了MIPS CPU的指令缓存，但禁用了它的数据缓存，将其变成了高速1KiB便签簿。墙/平面渲染例程广泛使用此便签簿。
为了研究VRAM是如何管理的，我通过不使用$PSX仿真器实时VRAM查看器进行了一次有趣的尝试。显示整个1024x512x16位像素(尽管失真)。该查看器还提供了CPU按帧发出的所有GPU命令的完整列表。仔细观察第一帧的(大小合适的)VRAM可以做出很多推断。最明显的是左上角的两个256x240x16位区域，它们是帧缓冲区(因此游戏是双缓冲的)。请注意，256x240是PSX可以达到的最低分辨率。在帧缓冲区下面是一组五颜六色的像素，它们是CLUT调色板。请注意，有红色阴影表示损坏屏幕淡出使用预先计算的调色板。在右上角，我们看到纹理被奇怪地水平挤压，并且颜色错误。这是因为纹理对前面提到的CLUT使用8位索引。
早在2018年，我就留出了一些时间来研究火灾效果是如何产生的[18]。通过查看GPU命令来重新访问它是相当酷的。注意每个命令目标区域是如何由no$psx用红色勾勒出来的。步骤1：在RAM中更新FIRE并将其上载到VRAM(CpuToVram命令)。步骤2：在屏幕上绘制四次火纹理(QuadTex命令)。FIRE纹理是32个纹理元素宽，但是利用GPU绘制它64个像素宽。这里没有可用的双线性滤波，这都是最近的采样。第三步：最后的末日盘被画在所有东西的上面(QuadTex命令)。
看一看一帧中发出的所有命令，就会发现该引擎与PC版本完全不同。在后者中，世界从近到远都被穿越。首先渲染所有的墙。然后(Visplan)之间的垂直间隙在第二个通道(包括天空)上被填充。第三次也是最后一次通过使精灵从远到近的顺序。所有这些都是在零像素覆盖的情况下完成的。在PSX上，渲染是以稍微更暴力的方式完成的。所有内容都在一个由远到近的通道中渲染。用于填充墙之间空隙的粘面系统已不复存在。平面和墙都是在每个分区的基础上渲染的，这要归功于一个名为树叶的新概念。GPE矩阵投影功能的广泛使用使这种真正的3D方法成为可能。精灵也与墙/平面同时渲染，没有任何遮挡测试/剪裁，这会导致一些透支。Void R_RenderPlayerView(Void){R_BSP()；//第一阶段R_RenderSKY()；//第二阶段(第一阶段开始的所有分区){R_RenderAll(分区)}R_Render_Hud_Weapons()；}。
让我们详细看看每一步，从首先用CopyRectRaw渲染的天空开始。No$psx将VRAM显示为帧的末尾，但允许在命令历史记录中后退。天空像素仍然可以看到，只是因为没有$PSX在处理1个像素宽的黑客攻击方面有困难(其他仿真器，如ePSXe也不会执行得更好[19])，但是所有这些都会被覆盖。请注意天空纹理下方的门关键点标记是如何贴图在一起的。接下来，以远到近的顺序遍历BSP。对于每个子地段，将渲染所有墙/平面/精灵。如果您熟悉doom bsp，您可能还记得doombsp编译器过去只存储子地段中的实体段。为了支持平面渲染，引入了一个新的概念"；叶子"；来存储BPS拆分段(它们是不可见的)。这些线段在屏幕空间中投影以生成平面边界。T