末日的多边形:PSX

2020-09-28 13:36:42

查看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