我该如何安装从金山毒霸下载的DLL文件？
1、从金山毒霸下载压缩文件。
2、将DLL文件解压到电脑上的某个地方。
3、把该文件跟要求使用它的程序放在同一路径上。注意32位程序需要使用32位的DLL文件，64位程序需要使用64位的DLL文件。否则会出现0xc000007b报错。
如果问题仍没有解决，把文件放到你的系统路径。它的替代路径是在：
确保覆盖现有的全部文件(但保留一个原文件备份)。
如果问题仍未解决，请按以下步骤注册DLL文件：
1、一个提升权限运行的控制台窗口。
(1) 具体操作是单击“开始”，单击“所有程序”，单击“附件”，单击“命令提示符”，然后单击“以管理员权限运行”。
(2) 在Windows 8/10中，进入“开始”界面。键入“cmd”，Windows会找到“命令行命令行”。单击“命令命令行”，选择“以管理员权限运行”。
(3) 如果要求输入管理员密码或确认，输入密码，或点击“允许”。
1、通过依次方法打开一个提升权限运行的命令行窗口。
古人有语：以史为鉴，可以知兴替。
历史如此，技术亦然。通过研究现代引擎的演变历史，可以更加系统、详细地了解引擎的技术内幕，从而掌握底层原理，挖掘规律，预判技术或行业的未来。恰好这段时间笔者通读了1000多篇各类论文和文献，抽取了其中的数百篇文献，总结归纳成此篇文章，以飨同行。
用于优化VR等渲染的MultiView对比图。上：未采用MultiView模式的渲染，两个眼睛各自提交绘制指令；中：基础MultiView模式，复用提交指令，在GPU层复制多一份Command List；下：高级MultiView模式，可以复用DC、Command List、几何信息。
Arm在UE上使用4-视图的多视图进行注视点渲染，可以减少65%的渲染工作量。
本篇将时间作为主线，划分成几个部分：
内容主要围绕着游戏引擎的架构和渲染部分，但不仅仅限于此，还包含相关的模块或笔者认为值得关注的内容。
游戏引擎始于1990年代中期，尤其是与第一人称射击游戏 (FPS) 等3D游戏相关，也就是Doom（下图）和Quake游戏的流行，其他开发人员不用从头开始工作，而是授权软件的核心部分并设计自己的图形、角色、武器和关卡。
左：Doom游戏截图；右：Doom 3游戏截图。
尽管游戏引擎的术语在1990年代才首次使用，但在1980年代也有一些较早的系统也被认为是游戏引擎，例如Sierra的AGI和SCI系统、LucasArts的SCUMM系统和Incentive Software的Freescape引擎。然而，与大多数现代游戏引擎不同，这些游戏引擎从未用于任何第三方产品。后来的游戏，例如Quake III Arena和Epic Games的1998 Unreal，在设计时就考虑到了这种方法，引擎和内容是分开开发的。至少，可重用引擎使开发游戏续集变得更快、更容易，这在竞争激烈的计算机游戏行业中是一个宝贵的优势。
在早期的PC开发游戏，最简单的游戏循环如下所示（想必学过windows开发的同学肯定接触过）：
上面的Draw函数绘制过程（OpenGL为例）的最简单的实现如下：
当然，以上只能对应简单案例，例如绘制Hello World这样的场景。对于复杂的场景，需要引入更多技术、加入更多调用，从而形成更复杂的游戏主循环。下图是提及的一种场景节点的交互图：
空间类、节点类、几何类和渲染类之间的相互关系。
在当时，场景的节点组织结构以继承为主（尚未出现Entity-Component和ECS），物体的数据结构以Entity为节点：
早期游戏场景的Entity节点结构图例。
早期游戏场景的Entity节点结构图例2。
随着时间迁移，各种新兴的渲染技术和硬件的进步（如纹理映射、抗锯齿、像素和顶点着色、改进的阴影生成、增加的内存带宽、增加的填充率……），使得游戏的环境更加逼真，而且它们也愈加复杂、绚丽。（下图）
随着物体、光源的增加，渲染技术越来越复杂，使得渲染状态需要执行复杂的管理，以便提升效率。下图是阐述的渲染状态更新技术：
更新渲染状态的情况。通过树状结构，游戏引擎可以方便地收集依赖关系和渲染状态。
在光照上，此时期的游戏常以多纹理获得光照效果。（下图）
多重纹理以获得暗图和光图。左上：木质的主要纹理，右上：与主要纹理结合的次要纹理，左下：一张暗图，下中：使用硬叠加的光照图，右下：使用软叠加的光照图。
CryEngine1为太阳阴影提供了阴影贴图和每个对象的投影阴影。为了提升性能，预先计算了植被阴影，但内存限制为非常模糊的纹理。对于高端硬件配置，CryEngine1为植被添加了阴影贴图，但将它们与预先计算的解决方案结合起来依然有不少问题。
CryEngine1将模板阴影用于点光源，以获得更简单、更有效的解决方案。CPU蒙皮允许在CPU上提取阴影轮廓，然后在GPU渲染模板阴影。很显然，当想要渲染更详细的对象时，这种技术会成为一个问题，因为它依赖于CPU蒙皮，需要额外的CPU计算、上传到GPU、边缘数据结构的额外内存，并且几乎没有可预测的性能特征。由于缺少对alpha混合或经过测试的阴影投射器的支持，因此该技术甚至无法用于棕榈树（下图）。
Far Cry游戏截图，使用了软预计算阴影与实时阴影相结合的方案。
在此阶段，已经诞生网格的LOD技术，下图展示了同一个网格的两个LOD的外观和三角形数量：
地形渲染也初见雏形，拥有了较大的视野、LOD过渡、特殊的纹理过滤（如双线性、各向异性）和雾效：
在此阶段，也已经兴起了Billboard（公告板）技术，用于粒子特效及部分远景物体的模拟。
DirectX是微软定制的图形API标准，是当今非常流行的主流图形API标准之一，是一组应用程序编程接口 (API)，专用于Microsoft平台上处理与多媒体相关的任务，尤其是游戏编程和视频。最初，这些API的名称都以“Direct”开头，如Direct3D、DirectDraw、DirectMusic、DirectPlay、DirectSound等。DirectX这个名称是作为所有这些API的缩写词（X代表特定的API名称）而创造的，并很快成为该集合的名称。
随版本变化的DirectX图标。
微软最早于1995年发布DirectX 1.0版本，随后几乎保持一年一发布的速度。截至1999年，已经发展到了DirectX 7.0。1996年微软发布了DirectX 2和3两个大版本。另外，因特殊原因，DirectX 4从未被公开发布。（下图）
DirectX 3.0的图形特性包含硬件级加速的位图、表面、线条绘图，支持高位图的颜色深度，拥有一个支持MMX的光栅化器。
DirectX 5.0的图形特性包含新增直接将多边形信息直接传递到硬件的DrawPrimitive接口、程序化网格和增强的动画、与排序无关的抗锯齿、基于范围的雾、各向异性纹理过滤、无缓冲隐藏表面消除等。
DirectX 6.0的图形特性包含更快的性能、用于更好照明和转换的更好的几何引擎、为具有硬件3D加速器的用户提供更快的软件光栅化器，以及对多纹理、凹凸贴图、纹理压缩、模板缓冲区和W缓冲区等。
DirectX 7.0的图形特性包含多纹理（组合两个或多个纹理贴图，如光照贴图）、立方体环境贴图、硬件变换和光照、顶点混合（GPU骨骼蒙皮）等。
DirectX 7的立方体环境图效果。
DirectX 7的顶点混合（GPU骨骼蒙皮）效果。图左没有顶点混合，图右启用了顶点混合。
**OpenGL（开放图形库）**是独立于平台的2D和3D可视化规范标准，由Silicon Graphics Inc于1992年推出，ARB（架构审查委员会）联盟负责其开发，会员为各大软硬件厂商（ATI、NVIDIA、英特尔、微软等），2006年由联合接手其开发。OpenGL的一个特点是开发缓慢，因为规范化是一个缓慢的过程，极大地阻碍了图形密集型应用程序的开发者。
在1999年及之前，OpenGL发布的版本和特性如下表所示：
| 一组基准功能、支持扩展 |
| 3D纹理、BGRA和打包像素格式、成像子集 |
OpenGL存在开发扩展套件，是一个开源的多平台库，用于桌面上的OpenGL、OpenGL ES和Vulkan开发，提供了一个简单的API，用于创建窗口、上下文和表面，接收输入和事件。它具有如下特点：
除了GLFW，还有GLEW、GLUT、gl3w、glad等等扩展库，具体列表见：。
1995年，Nvidia发布了NV1的显卡，晶体管达到100万个，特性是16位色彩、最近点过滤，性能达到每秒处理5万个三角形、100万个像素和
1996年，3dfx公司发布了 Voodoo 1代GPU，是第一张3D加速卡（4MB RAM，50 Mhz），仅支持3D可视化，需要一个额外的2D视频卡，在市场上获得巨大的成功。它的理念是将2D变换由快速的2D显卡执行，例如流行的Matrox视频卡，而3D变换由Voodoo卡执行，Voodoo的硬件能够进行比软件渲染更快的计算。
一个典型的Voodoo Graphics PCI扩展卡包括一个DAC、一个帧缓冲处理器和一个纹理映射单元，以及4 MB的EDO DRAM，DRAM和图形处理器以50MHz运行。它只提供3D加速，因此计算机还需要传统的视频控制器来处理传统的2D软件。
搭载Voodoo 1芯片的显卡外观。
同年，NVIDIA和ATI（后被AMD收购）开始了自己的GPU系列，例如Nvidia的（NV1、RIVA 128、Geforce 256），ATI的3D Rage、Rage Pro、Rage 128等。显卡一经面世，立刻大受欢迎，主要原因是合理的价格、广泛的销售渠道和被游戏和操作系统（主要是Windows）支持。
在随后的短短两年内，3dfx公司陆续推出了Voodoo Rush、Voodoo 2等芯片。Voodoo Rush将2D和3D统一在了一块，无需额外的2D处理器。但由于2D和3D的带宽争用，Voodoo Rush性能并不佳。
此外，Rush芯片组并不直接存在于PCI总线上，而是必须通过2D芯片的链接寄存器进行编程。与Voodoo Graphics一样，没有中断机制，因此驱动程序必须轮询Rush以确定命令是否完成；通过2D组件的间接性在这里增加了显著的开销，并倾向于备份PCI接口上的流量。与Voodoo Graphics相比，典型的性能损失约为10%，在窗口模式下甚至更糟。Voodoo Rush卡的销售非常糟糕，并且这些卡在一年内就停产了。
1998年3月，Voodoo 2面世，架构上和1代类似，但硬件上增加了第二个纹理单元，支持一次绘制两个纹理。Voodoo 2需要三个芯片和一个单独的VGA显卡，性能上比同期其它产品都要好，但也存在一些限制。Voodoo2引入了扫描线交错 (SLI)，其中两块Voodoo2板连接在一起，每块画出屏幕扫描线的一半，SLI将支持的最大分辨率提高到 。由于使用三个独立显卡（两个 Voodoo 2 SLI加上通用2D图形适配器）的高成本和不便，Voodoo2 SLI方案对总市场份额的影响很小，在财务上并不成功。
几个月后，带有集成2D/3D芯片组的Nvidia RIVA TNT（下图）发布，对Voodoo2的霸主地位构成轻微挑战。RIVA TNT添加了第二个像素管线，使得渲染速度翻倍，并且使用了更快的内存。与Voodoo2不同，它还增加了对32位（真彩色）像素格式、3D 模式下的24位深度缓冲区、8位模板缓冲区和对像素纹理的支持。此外，改进的mipmapping和纹理过滤技术，包括新添加的对三线性过滤的支持，与TNT的前身相比显著提高了质量，TNT还增加了对高达16MiB SDR SDRAM的支持。与RIVA 128一样，RIVA TNT是单芯片解决方案。
1999年，Nvidia的GeForce 256（NV10）发布，特点是固定管线，支持DirectX7.0，硬件及坐标变换和光照，支持立方体环境图、凹凸贴图、2x各项异性过滤、三线性过滤、DXT纹理压缩等功能。
在90年代，显卡的部件和布局尚显简单，最明显的是散热装置，98年的显卡只需要少许散热片，到了03年，便需要风扇来散热（下图）。
显卡除了物理部件的改进，处理速度和带宽也在飙升，呈现或超越摩尔定律曲线。下图是NVidia的从TNT（1998）到GeforceFX 6800（2004）每秒处理三角形数的曲线图：
图形API标准和GPU硬件的发展，使得游戏引擎如虎添翼，在此时代有了较大的发挥空间。
人类历史上第一款电脑游戏通常认为是1962年的Spacewar，游戏中有两艘玩家控制的宇宙飞船在原始2D显示器上呈现，尽管更简单的游戏甚至更早之前就存在。早期的电脑游戏由低分辨率屏幕上的简单2D图形组成，这种趋势一直持续到1990年代。
1962年的电脑游戏Spacewar，通常被认为是人类历史上第一款电脑游戏。
运行早期游戏的硬件非常有限，迫使开发人员从系统中获取所有处理能力，例如用汇编语言对游戏进行编程，过去的游戏工程主要是关于低级优化。由于硬件有限，早期计算机游戏的架构非常少，仅由事件循环、状态表和图形例程组成。这些游戏彼此之间几乎没有共享可重用元素，这意味着新游戏通常是从头开始编程的。
在早期的冒险游戏中可以看到一丝早期类似引擎的架构，其中第一个是Colossal Cave Adventure，标志着基于文本的互动小说类型的开始，其中游戏玩法包括阅读设置的文本表示并输入简单的命令与之互动。基于文本的冒险在早期游戏中非常流行，后来，结合图形催生了图形冒险类型的架构，但结构非常简单，仅有状态表形式的游戏逻辑、最小级别数据和一个几乎难以识别的事件管理器。
尽管Adventure的架构很简单，但可以清楚地看到数据驱动设计的元素，这就是典型的游戏引擎：游戏的内容与代码明显分离。原则上甚至可以通过更改数据和不理会代码来创建游戏的修改版本。
（1980年）。虽然Adventureland的机制与原始Adventure几乎相同，但Zork和Mystery House在冒险游戏的开发中产生了两个分支。Zork和其他Infocom的游戏仍然是纯文本的，但具有极大改进的命令解析器，而Mystery House以基本图形为特色（尽管玩家命令仍以文本形式输入），开创了图形冒险游戏的类型。 尽管如此，Infocom的基于文本的游戏在一段时间内更受欢迎，有行业人士后来评论说，当时有限硬件上的图形处理剥夺了本来可以呈现的游戏深度。
1980年的太空恐慌（Space Panic）是一个单屏游戏，其中一个角色在一个屏幕上移动，躲避外星人，爬上爬下梯子并在地上挖洞。像Donkey Kong（Nintendo，1981年）这样的游戏增加了额外的功能，比如跳跃的能力。更进一步的发展出现在像《超级马里奥兄弟》（任天堂，1985年）这样的游戏中，它用横向滚动机制取代了单屏机制，并添加了其它功能。
在1980年代中期，有一些小型独立视频游戏工作室，研制小型的平台游戏，平台游戏通常是游戏玩家通过在静态和移动平台和壁架上奔跑和跳跃来导航角色穿过充满敌人的关卡（下图）。此类游戏取得了巨大的成功，让全世界的游戏玩家感到高兴。
与早期游戏架构的情况一样（冒险类型的游戏除外），关于早期平台架构的文献很少。Blow（2004）提供了一些见解，命名了一个 1990年代的2D游戏的一些模块（流式文件 I/O、声音、主要/杂项、模拟、快速2D图形），同时指出其它类型的游戏可能包含不同的部分，例如获得AI的一部分，可能会失去快速图形节点。
上世纪90年代之前，由于没有成熟的游戏引擎，开发游戏异常困难，并且会重复做很多类似的功能，生产力低下，画面效果颗粒感十足。
在开发游戏过程中，有些游戏工作室对每个游戏都是从新造轮子，这样的后果就是开发一个游戏的时间愈来愈长，并且发现竞争对手研发游戏的时间却在逐渐缩短。而缩短研制游戏周期的工作室正是采用了复用的思维，所有游戏和所有平台游戏共有的许多属性和功能都可以从他们的特定游戏中提取出来，将上一个项目抽象出可重复使用或基础的模块，以便快速用于下一个游戏项目，从而不断地缩短游戏开发时间。
这些工作室不仅发现了最初的一些通用模块，而且几乎认出了所有游戏的可通用组件并将它们集成到单个系统中可以重复使用以制作许多不同的游戏。他们知道游戏内容（图形和声音）可能需要在逐个游戏的基础上创建，由于游戏的外观和声音不同，但他们也意识到存在支持此内容的框架（或基础架构），而这主要是可抽象的。这个框架或系统被称为游戏引擎。
1990年代，具备系统的游戏引擎有两个系列，一个是ID的Doom和Quake系列，另一个是Epic Games的Unreal系列。
许多人认为计算机游戏（尤其是游戏引擎）的转折点是FPS类型的诞生，id Software发行了Wolfenstein 3D (1992) 和Doom (1993)，尤其是《毁灭战士》，广泛地流行游戏爱好者中。
Doom的架构也值得关注，Doom的核心软件组件（例如图形渲染、碰撞检测和音频）与游戏内容（例如艺术资产、游戏世界和游戏规则）分离，意味着用户可以在游戏中添加新的关卡、模型和其它资产，有效地创建自己的新游戏。虽然Doom的可编程程度很小，并且从它衍生的游戏继续像原始游戏一样玩，但多家公司授权id Software的Doom引擎来制作他们自己的商业游戏。因此，虽然不是第一个使用数据驱动架构的游戏，但将其流行归因于Doom或许并不牵强。
年），它继承了Doom的功能，具有真正的3D图形和客户端/服务器架构。Quake还提供了一个真正独立于游戏的游戏引擎，包含一个关卡编辑器和QuakeC（一种可以改变游戏行为的脚本语言）。这是对Doom将数据文件添加到游戏可执行文件的方法的重大改进，并且可编程性极低。Quake的引擎由两部分组成：客户端和服务器，所有输入（键盘、鼠标、操纵杆）和输出（3D 渲染、2D 绘图和声音）都发生在客户端，以及所有实际的游戏玩法，例如玩家运动和物理模拟、AI和QuakeC脚本都在服务器上进行。客户端从玩家那里获取输入并将其发送到服务器，服务器在固定的时间内处理游戏，然后将游戏的状态发送回客户端，客户端为玩家提供视听输出。
Quake的单人游戏和多人游戏都建立在这种架构之上。在多人游戏中，多个客户端通过网络层与单个服务器（通常在不同的机器上运行）进行通信，而单人游戏使用共享内存缓冲区进行通信，并且每个处理帧都在从客户端获取输入之间拆分，在服务器上处理游戏并在客户端上输出。
除了简化多人游戏中的同步问题（与Doom相比，所有玩家运行自己的游戏模拟并且机器同步进行），客户端-服务器架构强制执行模块化设计，简化调试并保持单人游戏和多人游戏代码相同。
和源代码模块的数量增长。随着时间的推移，引擎也变得更有条理，因为第一个版本中的源代码文件只存在于一个文件夹中，而后续版本将源文件组织成一个子文件夹树。在这些版本的引擎中都发现了几个模块：
研究中分析的所有引擎都是用C编程语言编写的，但是，引擎的第四个版本id Tech 4已经使用C++和面向对象的范式进行了完全重新设计。
聊完1990年代的Quake系列，回过头来再聊聊同期的Unreal引擎。
1991年的ZZT，基本上是一个游戏引擎，其中植入了游戏。该引擎公开了一种小脚本语言，虽然它非常基础，但它是一种完整的脚本语言，可以使用它来编写小游戏脚本。它有一个实时的所见即所得交互式编辑器，用于创建关卡，可以通过几次击键来回切换，添加一个关卡，进行游戏测试并对其进行迭代， 这种交互式工作流程确实是其中的关键。
ZZT的游戏模式和编辑模式。
Turbo Pascal是一个易于使用的编辑器，用于创建代码和编译东西，输入代码的几秒钟后它会被编译，接着就可以运行它。这种编码方式与之前使用的所有东西相比，创建东西的迭代过程体验十分友好。
在随后的若干年，随着技术的演变，Unreal编辑器先后尝试了Visual Base、wxWidget、Slate等UI框架，逐渐形成了如今的编辑器风格和交互方式。后续的Unreal Engine加入了Game Play框架，可以给开发人员快速提供一个可用和可扩展的基础：
Engine的目标是满足双方需求的 3D 引擎设计、基于对象的渲染器、尝试各种特殊效果，以及高质量的图像渲染器、用户驱动的图像处理等。
在架构上，以前是单个引擎、相同的建筑基础、开源和专有的问题，现在是两个分离的引擎、不同的架构、OpenGL独有的扩展（GLUT）。
Plasma Works Engine架构图。分为物体和渲染器，它们又引用了各种资源和对象。
在数据流上，客户端采用了命令驱动式机制，驱动物体和渲染器，最终渲染出画面像素和光源信息：
Plasma Works Engine的地形建模器涉及不少的包体接口，它们的交互关系如下：
在地形生成和处理上，采用了并行化的分布式架构：
下图是地形编辑器界面：
下图是地形并行化处理的界面：
虽然站在现在的角度，略显初级，但在当时，能够并行化处理是非不易，会遇到IO、纹理带宽、同步、设计模型等诸多方面的问题。
1995年，提到了一种4+1视图的软件结构：
4+1视图的软件结构。
这种视图的软件架构也可以引入到游戏引擎的架构设计中，比如揭示引擎核心类的UML图便是逻辑视图，引擎的工具链便是开发者视图，资源文件的加载分层和部署方式便是物理视图。
此阶段的引擎已大致成形，架构的组件大致如下所示：
若是细化各个模块，则是如下图所示：
时间来到新世纪，诞生了不少新的渲染引擎或组件，其中就有典型代表Ogre。作为Ogre的衍生引擎Ogre Golf，在Orge的基础上做了不少扩展，引入了许多特性和第三方库，并且研制了代表游戏，例如包含了忍者、机器人、消防栓、城堡、术士等物体的大型迷你高尔夫球场，该游戏支持多人联网互动。
在同期，还出现了Irrich、Delta3D、Panda、OSG等引擎，它们各具特色，在引擎的各项特性（渲染、功能、场景、地形、视觉、跨平台等）上的支持程度如下表所示：
此阶段引擎的逻辑循环和渲染循环如下所示：
// 修改场景物体的属性。
// 渲染场景上的物体。
// 呈现交换链（启用多缓冲的情况下）。
至此，游戏引擎的萌芽期总算顺利完成，逐渐形成了基础的模块、架构和渲染技术。
