在《帝皇:罗马》中优化渐变边界渲染

签署人: Bartosz Boczula IDZSupport KS Daniel Eriksson 已发布: 01/19/2020 最后更新时间: 01/03/2020

简介

《帝皇:罗马》是 Paradox* Development Studio 推出的最新大战略游戏,我们一直合作提升其在英特尔® 锐炬™ Pro 显卡 580 上的性能。这一工作非常有趣,我们需要采取略有不同的性能分析方式。我们遇到的问题不一定是性能不佳,也可能是渐变边界渲染系统偶尔引起的卡顿,这促使我们重新定义性能的真正含义。由于英特尔和 Paradox 开发人员进行了富有成效的合作,您现在可以在各种英特尔集成显卡硬件上畅玩游戏,实现流畅的帧速率。

这篇文章简述了双方的合作。首先,我们将介绍经典的性能分析及其结论。然后,我们将说明发现卡顿原因的过程,并对性能的经典定义提出质疑。在介绍了一些技术背景信息后,我们将详细研究有问题的系统,并了解它的功能和工作方式。最后,我们将讨论引入的优化和我们能够实现的结果。

初始性能评估

开发人员关系工程师开始开发游戏时首先需要确定的一个要点是性能限制因素。我们经常使用受 GPU 限制受 CPU 限制术语,它们的基本意思是性能方面的最大负面影响通常源于 GPU 或 CPU。我们在查找性能问题时通常会怀疑这两个硬件。

确定限制因素的一般规则很简单 - 如果 GPU 至少有 95% 的时间处于繁忙状态,则游戏受 GPU 限制,否则可能受 CPU 限制。但如果性能还受其他因素影响怎么办?如果每秒平均帧数不是“良好性能”的指标怎么办?

许多工具可用于确定性能限制因素,我个人偏爱 GPUView。它是 Windows* 评估和部署套件 (Windows ADK) 附带的免费分析器。该工具可帮助您快速了解 CPU 和 GPU 的运行情况,非常适合进行游戏性能分析。它还可以显示 GPU 和 CPU 线程需要处理的工作量。

我收集了《帝皇:罗马》(庞培补丁)的 GPUView 轨迹 - 游戏处于“暂停”模式,该模式会停止所有进行中的 CPU 模拟。我将摄像机平移到埃及上,埃及是游戏中拥有专用资产的特殊区域之一。

游戏在“暂停”模式下的 GPUView 轨迹
图 1.游戏在“暂停”模式下的 GPUView 轨迹。该轨迹包括三个渲染的帧,显示了 GPU 及活动线程上的工作。

图 1 展示了屏幕上带有三个帧的轨迹,如“翻转队列”所示。翻转队列显示垂直同步 (VSync) 与该应用在屏幕所显示数据之间的关系。如需获得更出色的显示效果,您可以切换垂直蓝线表示的 VSync 事件。您还可以看到“翻转队列”栏分为两个部分。纯色部分表示生成显示内容(通常由 Desktop Windows Manager (DWM) 完成)所花的时间,交叉阴影线部分表示数据等待 VSync 事件处理的空闲时间。

在此特定时间段内,GPU 在 99.66% 的时间内处于繁忙状态。您可以在“硬件队列”部分的右下角看到该值。根据前面提到的定义,这表示游戏受 GPU 限制。这意味着游戏工作负载的执行完全取决于 GPU 的效率,也就是说优化 GPU 内容将提高性能,而优化 CPU 工作负载则不会。

接下来,让我们看一下代表运行中 CPU 线程的绿色部分。工作量最大的线程几乎在 15% 的时间内处于忙碌状态,而工作线程的这一比率约为 3%。以上就是整个评估过程 - 我们确定游戏受 GPU 限制,CPU 工作对性能毫无影响。

接下来,让我们重复上述评估,但这次同时在后台运行 CPU 模拟(图 2)。在游戏开始阶段,我在找到开战理由后以罗马统领的身份发起了与萨谟奈人的战争,我的臣民与我并肩作战。我指挥的一支由 18,000 名士兵组成的罗马主力部队与 8,000 名士兵组成的敌军展开了激烈战斗,此外双方还进行了一场堡垒围攻战。此时游戏处于“畅玩”模式。

GPU 有 99% 的时间处于忙碌状态,这表明即使在运行模拟的情况下,游戏仍受 GPU 限制。现在,此时间范围内具有最大工作负载的线程在 32% 的时间内处于忙碌状态(在“暂停”模式下则只有 15%)。看起来运行模拟对 CPU 产生了重大影响。然而,游戏仍受 GPU 限制。

在了解上述信息之后,让我们看看初始性能评估。在英特尔锐炬 Pro 显卡 580 上,《帝皇:罗马》(庞培补丁)显然受到 GPU 限制,无论在“暂停”还是“畅玩”模式。GPU 是主要瓶颈,因此理论上讲是性能优化的最佳目标。

实际性能如何呢?性能非常出色 - 平均测试分数约为每秒 30 帧 (FPS),这意味着游戏性能很好。那还有什么问题呢?30 FPS 难道不意味着性能良好且游戏可流畅运行吗?

游戏在“畅玩”模式下的 GPUView 轨迹
图 2.游戏在“畅玩”模式下的 GPUView 轨迹。在游戏开始时捕捉的,描述了罗马人和萨谟奈人之间的战争,包括持续进行的陆战和围攻。

性能卡顿发现

尽管报告表示性能良好,但问题还是有。在“暂停”模式下,我可以畅玩游戏,未遇到任何性能问题。当我按下“玩游戏”按钮时,游戏仍然运行正常,但是当我开始平移摄像头时,每几帧就会出现一次性能故障 – 感觉像游戏跳过了一两帧。当我再次暂停游戏时,问题消失了。为了更直观地说明问题,我使用免费工具 PresentMon *收集了一些数据,该工具可帮助您进行性能测量。图 3 显示了 Y 轴上 present 之间的时间(以毫秒为单位)及 X 轴上的帧数。

present 之间的毫秒数
图 3.图表表示 present 之间的毫秒数。注意性能差异较大的不同部分,进入“畅玩”模式时开始出现差异,进入“暂停”模式时差异消失。

看着这张照片,我开始感到纳闷 – 也许性能并非我最初想象的那样黑白分明。我们平均获得了 30 FPS,但性能仍然“不佳”,我无法完全享受沉浸式游戏体验。此外,初始性能评估表明,我们完全受 GPU 限制,但后来我们突然发现 CPU 模拟也会影响性能,至少偶尔会这样。

起初,我认为由于问题是随 CPU 模拟产生的,因此它一定与 CPU 工作负载有关。或许是一些非常密集的计算使游戏偶尔受到 CPU 限制,或许是某种 CPU 工作需要与 GPU 同步,因而阻止了其执行。为了进行调查,我使用英特尔® Vtune™ 分析器(一种免费的 CPU 分析器工具)收集了轨迹。

进入游戏的“畅玩”模式
图 4.英特尔® VTune™ 分析器轨迹是在进入游戏的“畅玩”模式时捕捉的。橙色和红色框代表帧速率在下降。

事实证明,我考虑的所有因素都不是问题所在。图 4 在第一行中以蓝色图形显示了帧速率。我用橙色和红色框标记了较慢的时间段。在橙色框中,您可以看到性能下降与大量 CPU 活动密切相关,而红色框中则不是这样。此外,橙色框只出现了两次,即开始时和进入“畅玩”模式后。轨迹的其余部分包含的元素与红色框中的元素相同。

我向 Paradox 开发人员展示了这些结果。结构表明,橙色框表示模拟初始化的情况。最繁忙的线程很可能是所谓的会话线程,该线程负责执行游戏命令。橙色框表示新游戏中的第一个取消暂停状态,会话线程在第一次更新期间进行了一些初始设置,这导致帧速率下降。会话线程将停止负责图形用户界面 (GUI) 的渲染线程和主线程,因为游戏状态在更新时被锁定,并且在锁定时,GUI 无法查询信息,因此不会展现任何内容。

有趣的是,性能短期受 CPU 限制并没有引起这种永久性问题。如果造成了这一问题,那么在红色方框中,我们应该会在 GPU 停顿时看到单一线程上有大量连续工作。接下来只要测试 GPU 就行了。我使用内部工具以 DirectX* API 调用列表的形式记录了一次游戏过程。我们使用这一技术分析受 GPU 限制的工作负载。该技术仅记录具有所有相关数据的 API 调用,这意味着在测量工作负载时 CPU 似乎具有超快速度,完全不会影响性能。我重播了流,收集了数据并分析了结果。

帧时间和来自 GPU 流的绘制调用次数
图 5.帧时间和来自 GPU 流的绘制调用次数。

看来我找到了“罪魁祸首”。每隔几帧,GPU 就会有大约两倍的工作量要处理;在有一些额外绘制调用需处理(例如非剔除对象会有这种任务)时,有时会发生这种情况。我对这一情况进行了核查,发现绘制调用次数与性能峰值无关。

我感觉马上要找到根本原因了。GPU 每隔几帧就需要处理一些额外的工作,但没有太多的额外绘制调用。在这些帧中可能只有几个额外的绘制调用,或者某些绘制调用比平常要长很多。通过使用英特尔® 图形性能分析器(英特尔® GPA),我成功从流中捕捉到了一个帧(图 6)。

最后,我找到了卡顿的原因。实际上,在该帧中还有七个额外的绘制调用。它们的执行花费了将近 40 毫秒,这就解释了我一开始产生的“帧缺失”感觉。渲染该帧所花费的时间与渲染两个常规帧所用的时间相同。我将发现的结果报告给 Paradox,我们终于找到了根本原因 - 边界渲染系统在 GPU 上花费的时间过长。我请 Paradox 的开发人员 Daniel Eriksson 对该系统进行了进一步解释。

使用英特尔® GPA 工具捕捉的长帧
图 6.使用英特尔® GPA 工具捕捉的长帧。橙色框显示了快速帧中不存在的其他绘制调用。在集成 GPU 上执行它们大约需要 40 毫秒。

技术背景

在继续讨论之前,我想介绍一些后文中将用到的技术术语和算法。

距离场

距离场是一种有趣的技术,它利用纹理作为描述复杂形状的工具。您可以将这种纹理视为一个网格,其中每个像素(而不是颜色)保持到最近几何图形的距离。将国家之间的边界想象成几何图形 - 如果我们知道每个像素到该几何图形的距离,我们将能够在其周围实现良好的渐变,这正是 Paradox 在《帝皇:罗马》中所做的。

距离场纹理
图 7.距离场纹理(有时称为“地图”)的示例。左边的代表无符号距离场,右边的代表有符号距离场。请注意,此处的数值 0.0(代表形状)仅用于说明目的。在实际的纹理中,不需要如此明确。

在图 7 中,您可以看到两个非常简单的 5x5 距离场纹理。左侧的图像表示无符号距离场,而右侧的图像表示有符号距离场 - 符号告诉我们像素是位于几何图形的内部还是外部。由于我们要描述的形状(边界)没有“内部”,因此我们不可能有负值,因此仅使用无符号距离场。这也意味着非常接近边缘的精度将非常低:Paradox 要求艺术家在调整掩码参数时要小心,以免边缘出现伪影。

相比将普通纹理用作地图,距离场具有多个优点。首先,地图非常大,保持一个而非三个值(每种颜色一个)会大幅降低采样成本以及纹理大小。此外,当您接近线时,距离场有助于保持比普通纹理更高的质量。您可以将 5x5 纹理渲染为 1080p 渲染目标,并获得较细的清晰线条,而如果使用传统纹理,它会被放大且模糊不清。最后,游戏允许修改,这意味着玩家和创作者必须能够轻松修改地图。

Jump Flooding 算法

第二个重要术语是 Jump Flooding 算法 (JFA)。在《帝皇:罗马》中,JFA 被用于构造“距离场”纹理,但它还有其他用途,例如,构造 Voronoi 图。该算法的输入是一个纹理,其包含一些表示“无数据”的任意值,这些值为 JFA 提供了种子。在《帝皇:罗马》中,这些种子表示游戏世界的边界。然后,算法会对整个纹理处理两次,并为每个像素计算距离场。具体做法是对 8 个相邻像素(基本方向上 4 个,顺序方向上 4 个)进行采样,这些像素与给定像素保持着“步长”距离偏移。此“步长”因每个算法迭代而改变。利用所有 8 个像素的信息,它可以确定到最近边界的临时最近距离。

Jump Flooding 算法
图 8.Jump Flooding 算法,单个像素一次迭代的距离计算。

图 8 应帮助直观表示算法。红点是一个像素,我们将为其计算距离。橙色点代表八个采样点。黑线是种子,也就是几何图形或边缘。黑线表示《帝皇:罗马》中领土之间的实际边界。虚线表示每次迭代时都会更改为一个较低值的步长。请注意,对于该特定像素,由于存在更近的几何图形,这一结果不正确。但是,此问题将在进一步的迭代中得以解决,在这些迭代中,每个步长都将大幅降低。

渐变边界

《帝皇:罗马》中,国家之间的边界显示为地形的叠加层,黑色样条线表示边界的形状,颜色渐变将边界的每一侧与国家或其他数据相关联,具体取决于地图模式。在本文中,我只讨论颜色渐变。图 9 展示了该游戏中边界的概貌。通过两个独立的步骤可以实现颜色渐变:在“颜色地图”中进行颜色查找,以及从“距离场”纹理中采样。

主色和次色的应用
图 9.游戏画面的屏幕截图,显示了主色和次色的应用。Nepete 领土边界使用红色作为主色,表明这是罗马边界的终点。紫色是 Pyrgi 的主色,表明领土所有权,红色是次色,表明罗马目前占据着领土。

颜色查找

着色器可以使用三种不同的颜色:

  • 主色:您看见最多的颜色。用作地图模式的主色值,可在默认地图模式中显示主权国的颜色(在图 9 中为 Nepete 或 Carsioli 领土边界的红色)
  • 次色:该颜色与对角线条纹图案混合。用于地图模式的次色值,可在默认地图模式中在主权国家的颜色上显示条纹形式的入侵国家颜色(在图 9 中为 Pyrgi 上的红色条纹)
  • 突出显示:用于通过在上方混合一种颜色为玩家突出显示某省或某个区域(很少使用,未在图中显示)

我们将所有这些信息保存在“颜色地图”的纹理中。每当与游戏状态相关的因素发生变化(例如,一省更改所有权,另一个国家开始占领领土或玩家更改地图模式时),都会重新计算“颜色地图”(如图 10 所示)。右侧的图 11 显示了颜色地图保存颜色的布局。红色矩形表示主色的存储位置,绿色矩形表示次色,蓝色矩形表示突出显示颜色。

每当地图模式更改时,“颜色地图”就会填充新数据
图 10.每当地图模式更改时,“颜色地图”就会填充新数据。

我们可以使用一种间接级别获得用于地图上任何点的颜色。首先,对于要使用它的每个对象(例如地形或山脉),我们在像素着色器中将自然空间的点坐标归一化到 0-1 范围。然后,我们用它对一个巨大的查找纹理(8192x4096,R8G8_UNORM,左侧图 11)进行点采样,以获取 UV 坐标,用于从更小的颜色地图(256x256,R8G8B8A8_UNORM,右侧图 11)中获取主色值。我们可以通过简单地偏移坐标来获得次色和突出显示颜色。

颜色查找纹理和颜色地图
图 11.颜色查找纹理(左)和颜色地图(右)。“颜色查找纹理”包含要在“颜色地图”中使用的 UV 坐标,可帮助获取主色(红色矩形),次色(绿色矩形)或突出显示颜色(蓝色矩形)。

这种间接性有其原因 - 游戏开始时只需计算一次“查找纹理”,且仅需两个通道支持 UV 坐标。此纹理后续不会改变。我们需要计算此值,而不是从其中加载预定义资产,因为脚本和 mod 可更改省份的布局方式。然后,需要更新颜色时,我们只需要更新单个颜色地图,而非 3 个未经压缩的 8192x4096 4 通道纹理。

距离场纹理

我们需要的第二条信息是对颜色进行多大程度的混合,为此我们需要一个“距离场纹理”。

“距离场”部分非常简单 - 与颜色查找纹理一样,我们使用归一化的自然空间坐标对其进行采样。像素着色器对所有地形进行坐标归一化,并且“距离场纹理”进行多次采样以增强渐变顺畅度。距离场纹理中的每个像素都包含到“边缘”的近似距离。我们将此值与一些常量和艺术家可调整的参数结合使用,以计算在多大程度将颜色混合到地形中。

最终距离场纹理
图 12.最终距离场纹理。每个像素保持到最近边界的距离。

绘制边界

将艺术家提供的参数应用于从“距离场”中采样的距离后,我们就会获得“掩码值”。然后,掩码值可用于将我们从颜色地图步骤中获得的颜色混合到地形中。图 13 在一张图中显示了所有片段。

距离场之所以有效,是因为当使用线性滤波器采样时,低分辨率图像将提供与高分辨率图像几乎一样精确的结果。渐变边界系统使用无符号距离场,这将对靠近边缘的情况会产生一些精度问题。有符号距离场没有这个问题。如果您不熟悉有符号距离场,我建议您阅读 Valve *的 Chris Green 撰写的《为矢量纹理和特殊效果改进 Alpha 测试的放大倍率》。

计算地形渐变的所有必要组件。
图 13.计算地形渐变的所有必要组件。掩码是将艺术家可调参数应用于“距离场”值的结果。在这种情况下,“颜色地图”是对图 11 两种纹理进行采样的组合结果。白色虚线表示边界的大概位置。

计算距离场

剩下的问题是如何创建距离场。我们想要获得的结果是,“距离场”纹理中的每个像素包含到最近边缘的准确距离。在实践中,我们无法获得确切的结果,但是我们可以非常快地获得近似数值。

距离场是使用 Jump Flooding 算法在 GPU 上计算的。基本上,这意味着我们首先需要找到边缘,一旦找到边缘,我们就可以运行 JFA,并在 (O(log(n)) 迭代中将有关这些边缘的知识“传播”到相邻像素,其中 n 是最大传播距离。

在 GPU 上运行 JFA 通常需要至少两个像素的缓冲区,它们都支持往复读取和写入,即从一个纹理中读取并写入另一个纹理,然后交换两个纹理,以便在下一次迭代中读取前一次迭代的结果,并写入下一次迭代的输入。在我们的“渐变边界”系统中,这两个纹理使用R8G8_UNORM格式。在 JFA 中使用两个通道分别在两个轴中存储到最近边缘的距离,这使我们可以使用欧几里德距离指标来获得良好的精度。我们还具有R8_UNORM 纹理,用于存储最终的归一化距离(图 12)。

总而言之,“距离场”计算包括四个不同的步骤。

  1. 沿海边境通行证,它创建了一个掩码,用于中止在海洋省份设立沿海边境。
  2. 初始化步骤。如果所有采样像素都属于相同的“设立边境的目标区域”,该步骤可确保每个像素(用于为 JFA 育种的向下采样纹理中)包含(255,255);或者,如果在采样空间内发现多个区域,则包含(距离 x,距离 y);在此步骤中,我们将对“颜色查找”和“颜色地图”进行大量采样。
  3. 实际的 JFA 算法执行了五次迭代。
  4. 从 JFA 输出中创建距离场纹理。

下表简述了该过程的每个步骤。每张图片具有一个 64x64 纹理。初始化阶段中的点(由四个像素组成)代表 JFE 的种子。在游戏中,该点被国家边界取代。

init

初始化。对 JFA 育种时我们需要为其提供一些可用于扩展的初始数据。要创建此数据,我们运行一个通道,以使用前面提到的颜色采样方法检测边缘,并将查找纹理的大小降低 4 倍(更便宜的采样和距离场可表示 3 个像素之间的数据,因此适用于压缩距离)。4 个中心像素不是黑色的,但是在 x 和 y 轴中包含到另一种颜色最近像素的距离。黄色像素的值 (255,255) 表示与像素最近的边缘目前处于最远距离。

J F A 1

JFA 1。在第一次迭代中,每个像素将以 16 个像素的偏移量对相邻像素进行采样。如果到相邻像素的距离加上该相邻像素中存储的矢量长度,小于像素中存储的矢量的长度,则像素将更新其自身的数值。更新后,像素的新值将等于相邻像素的值加上到达该相邻像素的偏移量。

J F A 2

JFA 2。重复上一步,但偏移量为 8。

J F A 3

JFA 3。 同上,但偏移量为 4。

J F A 4

JFA 4。同上,偏移量为 2。

J F A 5

JFA 5。同上,偏移量为 1。很难看出此步骤与上一步之间的区别。请注意,在初始化步骤的中间环节,实际上有一个 2x2 的区域已初始化。如果仔细查看上一步中的纹理,您会发现,尽管没有间隙,但其他每个像素都会“过冲”并且不够精确。现在,每个像素都包含两个值,分别代表到 x 轴和 y 轴到最近边缘的距离,这些值可视为向量。

最后一步是创建渐变纹理

最后一步是创建渐变纹理。我们只需为每个像素计算这两个向量的长度,并完成了这些工作。

当然,这还不足满足 Paradox 艺术家的要求。上述检测不同颜色省份之间的边缘的方法适用于地图的多数部分。但是,我们还将对《帝皇:罗马》中的美丽海岸线(显示效果欠佳)进行渐变混合。我们尝试在边缘检测通道中仅忽略面向水的边缘,但是这引起了问题,例如两个国家被一条大河分开。

绿色:需要渐变的区域。红色:无需渐变的区域
图 14.绿色:需要渐变的区域。红色:无需渐变的区域。

解决方案是采用预通道对颜色进行超采样并创建一个掩码,以告知边缘检测需忽略的地图部分。它会搜索特定的“通配符”颜色,并将掩码设置为忽略作为通配符且只有 1 或 0 个非通配符颜色的任何像素的边缘。

下面是一个动画 GIF,显示了如何在整个地图中为 JFA 的每个步骤填充距离信息。在 GPU 上运行的大规模复杂模拟及对大型纹理的大量采样是导致性能卡顿的原因。

整个地图的距离场计算的动画过程
图 15.整个地图的距离场计算的动画过程。

系统优化

在独立 GPU 上,计算渐变时的性能下降不是很明显。每当重新计算渐变时,我们都可以看到几毫秒的峰值,但是这些事件很少见,玩家一般只需即时按下按钮便可。我们从未在明显出现恼人峰值的集成 GPU 上分析该功能。经验总结。

我们开始分析该问题时首先注意到,这些重新计算事件并没有我们最初想象的那么罕见。结果表明,一个省的三种颜色的一种更新时渐变会立即更新,即使渐变仅依赖三种颜色的一种。此外,在重新计算渐变之前,我们从未检查过是否有任何实际变化。修复了这两个问题后,我们大幅降低了峰值频率,从每天玩游戏几乎出现一次峰值减少到每月大约出现一次。

但是每个峰值仍然非常明显且令人讨厌。在实施前两项修复后(仅在相关颜色变化时触发并确保在重新计算渐变时确实发生了变化),我们可以轻松地查看和测量需要更新的地图部分。大多数时候,我们只需要一次更新几个省。日志显示,我们要么更新几个省份,要么更新整个地图。还有一些处于两者之间的情况,但很少见。

有鉴于此,我们认为最划算的做法是针对常见情况进行优化,即一次同时更新几个省份。整个渐变边界更新非常类似于后期效果:面向覆盖整个剪辑空间的单个三角形的极简顶点着色器,以及用于实际工作的像素着色器。我们实施的优化将几何图形从整个地图的一个“全屏”三角形切换为四边形列表,其中每个四边形覆盖了距离场中需要更新的区域。简单、优雅且高效。这种优化本身不仅减少了 GPU 的工作量,而且还减少了样本数量,样本数量多是这种情况下性能不佳的主要原因之一。有很多样本来自非常大的纹理,这导致高速缓存效率低下,使用户必须从系统内存中获取数据。

生成四边形也非常简单。我们已经知道每个省份与轴对齐的边界框,因此我们只需将其屋顶或地板转换为四边形,但要保持一些额外宽度,以便四边形覆盖渐变可影响的最大区域。换句话说,我们以距离场的最大距离挤压四边形的每一侧。当有多个区域需要更新时,这些区域的四边形有可能会重叠,这意味着一个像素可能要计算两次,我们不希望如此。为了避免重叠问题,我们让 CPU 运行算法,以在渲染之前剪切与合并背景线程上的重叠四边形。在临界点,四边形合并任务花费的时间将超过节省的时间(不同硬件上的临界点不同),因此我们需要针对常见情况(仅更新 1-10 个省份),当需要的四边形数量足够大时,我们将恢复更新整个地图。

在图 16 中,您可以在玩家吞并了包含大约 6 个省的国家后生成的四边形。由于我们知道该区域之外的任何内容都没有更改,因此我们只能在这个小区域而不是整个地图上运行 JFA。四边形边缘附近的像素可以安全地对该区域外部的像素进行采样,并且仍然产生相同的结果。

优化之后,仅需要更新“距离场”纹理的一部分
图 16.优化之后,仅需要更新“距离场”纹理的一部分。四边形代表玩家吞并包含 6 个省的国家后需要更新的区域。

结论

如您所见,性能并不总是受限于 CPU 或 GPU,是评估玩家满意度的重要指标。得益于 Paradox 开发人员的出色工作,卡顿问题得以解决,现在更多玩家可以摆脱卡顿,尽情享受游戏的乐趣了。

最后,我要感谢 Paradox Development Studio 的 Daniel Eriksson 共同撰写这篇文章,并感谢 Marcus Beausang(也来自 Paradox Development Studio)对本文进行了审阅和最后润色。同时,我要感谢英特尔的 Adam Lake 提供了大量审阅支持。他们的意见无疑增加了我的修改工作,但这完全是值得的,而且文章在修改之后相比初稿也显著改进。

工具和参考

获取 Windows 评估和部署套件 (Windows ADK)

获取帮助进行性能测量的免费工具 PresentMon*。

获取免费 CPU 分析器工具英特尔® Vtune™ 分析器。

Valve *的 Chris Green 撰写的《为矢量纹理和特殊效果改进 Alpha 测试的放大倍率》。

产品和性能信息

1

英特尔的编译器针对非英特尔微处理器的优化程度可能与英特尔微处理器相同(或不同)。这些优化包括 SSE2、SSE3 和 SSSE3 指令集和其他优化。对于在非英特尔制造的微处理器上进行的优化,英特尔不对相应的可用性、功能或有效性提供担保。该产品中依赖于微处理器的优化仅适用于英特尔微处理器。某些非特定于英特尔微架构的优化保留用于英特尔微处理器。关于此通知涵盖的特定指令集的更多信息,请参阅适用产品的用户指南和参考指南。

通知版本 #20110804