游戏引擎学习第18天

clang-format 相关的配置可以参考下面

.clang-format 是用来配置代码格式化规则的文件，主要用于 Clang-Format 工具。以下是 .clang-format 文件中的一些常用设置：

1. 基础设置

Language: Cpp                # 指定语言 (C, C++, Java, JavaScript, etc.)
BasedOnStyle: Google          # 继承某种预设风格 (LLVM, Google, Chromium, Mozilla, WebKit)
Standard: C++17               # 指定标准 (C++03, C++11, C++17, etc.)
IndentWidth: 4                # 缩进的空格数
TabWidth: 4                   # Tab 替换为空格后的宽度
UseTab: Never                 # 是否使用 Tab 替代空格 (Always, Never, ForIndentation)

2. 换行和对齐

ColumnLimit: 80               # 每行最大字符数，超过自动换行
AlignConsecutiveAssignments: true  # 对齐连续的赋值语句
AlignConsecutiveDeclarations: true # 对齐连续的声明
BreakBeforeBraces: Allman      # 控制括号的换行风格 (Attach, Linux, Allman, Stroustrup)
AllowShortFunctionsOnASingleLine: Inline  # 短函数是否允许单行书写

3. 空格规则

SpaceBeforeParens: ControlStatements  # 控制语句后是否加空格
SpaceAfterCStyleCast: true           # C风格强制类型转换后是否加空格
SpaceBeforeCpp11BracedList: true     # C++11 列表初始化前是否加空格
SpacesInAngles: false                # 模板参数尖括号内是否加空格

4. 注释相关

CommentPragmas: '^NOLINT'            # 设置特殊注释的格式
ReflowComments: true                 # 自动调整注释换行
MaxEmptyLinesToKeep: 1               # 保留的最大空行数

5. 函数和参数

AllowAllParametersOfDeclarationOnNextLine: true # 函数参数可以换行
BinPackArguments: false                         # 函数参数按每行一个排列
BinPackParameters: false                        # 函数声明参数按每行一个排列

6. 指针和引用

PointerAlignment: Left              # 指针和引用的对齐方式 (Left, Right, Middle)
DerivePointerAlignment: false       # 是否根据代码风格自动推导指针对齐方式

7. 命名空间和导入

IncludeBlocks: Regroup             # include 分组 (Preserve, Merge, Regroup)
SortIncludes: true                 # 按字典序排序 include 语句
NamespaceIndentation: All          # 命名空间内的缩进 (None, Inner, All)

8. 类和结构体

AccessModifierOffset: -2           # 类访问修饰符（public/private）缩进的偏移
ConstructorInitializerIndentWidth: 4  # 构造函数初始化列表缩进宽度

完整示例

以下是一个综合 .clang-format 示例：

Language: Cpp
BasedOnStyle: Google
Standard: C++17
IndentWidth: 4
TabWidth: 4
UseTab: Never
ColumnLimit: 120
BreakBeforeBraces: Attach
PointerAlignment: Left
AllowShortFunctionsOnASingleLine: None
BinPackArguments: false
SpaceBeforeParens: ControlStatements
SortIncludes: true
NamespaceIndentation: All
AlignConsecutiveAssignments: true
ReflowComments: true

根据你的项目需求可以选择性添加或调整设置。

为什么我们需要强制视频帧率

这段文本提到的是游戏开发中的一些技术挑战和开发者的思考过程。以下是对内容的复述和总结：

1. 同步与定时问题：

   • 开发者讨论了如何创建一个合适的定时回路来驱动游戏，这样可以确保游戏的顺畅运行。当前，平台层面存在潜在的音频延迟和同步问题，开发者指出，在理解和调整时序之前，无法确保游戏的表现是稳定的。

2. 平台层与性能问题：

   • 开发者提到，他们计划在平台层上做一些性能调优工作，尤其是在Windows NT系统上进行调优，但这些工作一直被推迟。调优值的正确性与游戏性能密切相关，开发者强调，若平台层定时出现问题，最终可能导致游戏中的错误调整，影响游戏的可玩性。

3. 游戏调优与错误决策：

   • 他们还提到，早期做出的每个决定都会影响到游戏的整体表现，因此需要在开发过程中谨慎处理调优。如果在后期进行最终调优时发现错误，这可能导致需要重做大量工作。

4. 源代码访问与开发透明度：

   • 开发者提到，预定游戏的用户可以通过电子邮件获取源代码的下载链接，鼓励大家跟进源代码的变化，并参与到开发过程中。

5. 工具与开发过程：

   • 开发者尝试了名为“平滑绘制”的工具，尽管它与Microsoft Paint差异不大，但依然给了它一个机会，并表示愿意继续尝试。开发者还提到，接下来将复习项目的目标，并确保每个人都明白游戏开发的高层目标。

6. 开发建议与思路：

   • 开发者强调，在开始编码之前，应该首先回顾项目目标，确保团队的目标一致，并在开发过程中避免过早定型错误。

综上所述，这段文字展示了开发者在面对技术难题时的谨慎态度，以及他们如何一步步确保游戏开发过程中的每个决策是基于合理的时序和性能考量。此外，也涉及到团队合作、工具评估以及源代码管理等方面的内容。

绘制并解释帧计算和显示时间线

绘制并详细解释帧计算和显示时间线：

1. 帧计算（Frame Computation）：

   • 当我们谈论视频游戏或图形应用时，帧计算指的是在每一帧的时间间隔内，程序执行的计算任务。这个过程包括了物理计算、动画更新、图形渲染等。每个帧的计算在固定的时间间隔内进行，确保图像更新顺畅、连续。

2. 时间轴（Timeline）：

   • 时间轴表示图形或视频渲染的时间流。每一帧在时间线上都有一个特定的时刻，表示它何时开始渲染、计算或显示。通过时间轴，可以清楚地看到每个步骤的顺序和帧的生命周期。

详细过程描述：

• 游戏启动：

  • 当我们启动游戏或应用程序时，首先需要执行操作系统的启动过程，这涉及到初始化程序、加载必要的资源等。然后，我们进入正式的时间计时，开始衡量帧的渲染与计算时间。

• 帧零（Frame Zero）：

  • 在某一时刻（称为 t0），程序开始计算和渲染第一个帧。这个时刻被称为“帧零”。此时，计算的目标是生成一个初始帧，通常会进行一系列计算（如物理模拟、动画计算等），并将其渲染到屏幕上。

• 延迟与计算：

  • 在帧计算过程中，可能会经历一些延迟。例如，在游戏开始时，可能只显示黑色背景，直到所有计算和准备工作完成。这一阶段没有视觉输出，只是为了确保渲染系统能够正确初始化和准备好显示帧。

• 显示帧：

  • 一旦第一个帧（帧零）计算完成并渲染，它会显示在屏幕上，音频和视频的同步开始。在此之后，每一帧的计算和显示都会按照固定的时间间隔进行。尽管每一帧的计算过程是持续的，但显示的时间是固定的，例如每帧显示 16.66 毫秒（即 60 帧每秒）。

• 固定持续时间：

  • 显示每帧的时间是固定的，这意味着每一帧的显示时间段是恒定的。即使计算时间不同，屏幕上的显示时间不会改变，这样可以确保视觉上的一致性。

• 视频与音频同步：

  • 在理想情况下，视频帧的显示和音频的播放是同步的，确保用户体验的连贯性。如果计算完成并开始显示后，音频和视频应同时出现，避免不同步的问题。

• 可变帧率（Variable Frame Rate）：

  • 在一些应用中，尤其是高帧率显示器上，可能采用可变帧率技术。这意味着帧的计算和显示可以根据系统负载的不同调整。这与固定帧率（如 60 帧每秒）不同，可能会导致帧率变化，从而影响画面流畅性。

• 用户体验：

  • 对于用户来说，整个过程应该是流畅的。当计算完成并开始渲染帧时，用户看到的是一致且流畅的图像与音频。如果计算过程过长或中断，可能会导致卡顿或延迟，从而影响体验。

解释可变帧率显示器

这段内容主要讨论了可变帧率显示器（Variable Frame Rate Monitors）以及它们如何影响游戏的流畅度和动画效果。以下是详细的总结：

1. 帧率与显示器刷新：

   • 标准显示器有固定的帧率，例如每秒60帧。这意味着每隔一定的时间（例如16毫秒），显示器会更新一次图像，显示新的一帧。
   • 如果帧率过高或过低，可能会导致画面卡顿或撕裂现象。为了避免这种情况，我们希望显示器的刷新率与游戏或计算机生成的帧速率一致。

2. 同步问题：

   • 如果显示器的刷新频率和计算机生成帧的频率不匹配，就可能导致帧丢失或跳帧。例如，如果显示器每秒更新60帧，而计算机生成的帧速率为70帧，那么显示器无法处理额外的帧，可能会重复显示某一帧，造成画面不流畅。
   • 这种情况会使得动画的速度显得不自然，用户体验下降。因此，保持显示器刷新率和帧生成频率的一致性是很重要的。

3. 可变帧率（VFR）显示器：

   • 可变帧率显示器的工作原理是能够根据内容的渲染速度动态调整刷新频率。这意味着当帧渲染速度较快时，显示器会相应提高刷新率；而当帧渲染速度较慢时，显示器则降低刷新率。
   • 这种灵活的刷新率有助于减少撕裂和卡顿现象，提升用户体验，尤其是在处理复杂的游戏和图形时。

4. 问题与挑战：

   • 可变帧率显示器并不是完美的解决方案。在实际使用中，计算机的渲染和显示器的刷新并不总是同步。这种不同步可能导致预测错误，尤其是在帧的渲染时间不稳定时。比如，在某些情况下，显示器可能提前渲染一个帧，而这时物理引擎还未准备好更新游戏状态，导致动画变得不连贯。
   • 这种不同步会让游戏的物理效果看起来不真实，甚至导致某些游戏操作的响应变得不准确，影响游戏的流畅性和可玩性。

5. 结论：

   • 虽然可变帧率显示器能够在一定程度上改善视觉体验，但它并不总能完美解决所有问题。事实上，固定帧率监视器可能更有用，尤其是在能够保证固定帧速率的情况下。如果能保证帧速率的稳定性和一致性，固定帧率显示器反而会提供更为平滑的体验。
   • 可变帧率的优势在于它可以让游戏和显示器的刷新速率更灵活地适应不同的场景，但前提是游戏能够稳定控制帧速率。如果帧速率不稳定或无法保证，显示器的可变帧率可能带来更多问题。

6. 个人观点：

   • 讲解者认为，如果能够保证帧速率的一致性，固定帧率的显示器可能更为理想。对于游戏开发者来说，确保帧速率稳定是关键，任何技术（如可变帧率显示器）如果不能解决根本问题，反而可能引入更多复杂性。

总体来说，这段内容强调了可变帧率显示器的优缺点，尤其是在确保平滑动画和避免撕裂方面的挑战，以及它如何与计算机生成的帧速率配合使用。

游戏循环设计概述

目标帧速率设计概述：

我们努力确保达到目标帧速率。如果出于某种原因未能达到目标帧速率，我们会选择一个新的较低的帧速率，并尽力保持这一固定帧速率，而不是让帧速率变动。如果我们原本设定的是60帧，而没有达到，我们可能会降到30帧之类的更低帧速率。

但我不希望帧速率是可变的，因为可变帧速率很难正常工作，特别是当涉及到物理计算时，这会导致错误。如果我们选择一个固定帧速率，那么帧循环就会根据这个固定的帧速率来工作。

帧循环的设计如下：首先，根据目标毫秒来更新物理世界，然后进行渲染和页面翻转。这个过程会持续进行，并且确保每一帧都基于目标毫秒进行处理，尽量在目标毫秒接近时进行页面翻转。

如果我们在同步模式下进行，确保与显示器的刷新率（比如垂直空白）同步，这样能够保持流畅的显示。

音频问题：

音频方面也有挑战，理想情况下，我们希望每一帧都能精确地处理相应的音频量。但如果错过了某一帧的音频处理，就会出现帧延迟，导致音频跳跃。为了避免这种情况，我们有两个选择：确保音频的准确性，或者采取其他措施以确保音频总是按时播放。

总结来说，设计一个固定帧速率的游戏循环有助于确保平滑的物理更新和渲染，而音频则需要精确控制以避免延迟和跳跃的问题。

有两种方式来确保音频总是准时播放：

1. 始终按时提供音频：这意味着我们的帧速率是一个硬性约束，游戏程序需要确保每一帧都准时到达，不会错过任何一个框架。

2. 提前提供音频：另一种方法是提前提供音频，即提供比当前帧更多的音频。可以通过以下两种方式实现：

   • 让音频提前一帧或者半帧，来处理音频延迟。
   • 或者提前写一整帧的音频数据，这样可以减少音频延迟，但会导致一定的帧延迟。

还可以考虑使用线程来等待更新或处理音频流的紧急刷新。最终，选择哪种方法取决于开发者的优先级和目标。需要注意的是，没有一种方法是绝对正确或错误的，它们只是依据不同的需求做出的决策。

开发者通常需要确保每一帧都达到目标帧率，如果无法实现目标帧率，则需要优化程序以满足要求。选择这种方法能够确保游戏帧率稳定，而不会影响音频播放。

此外，还需要处理显示器的刷新率问题，确保游戏以正确的刷新速率运行。

多显示器讨论

这段对话主要围绕如何在程序中获取显示器的垂直刷新率展开。详细的中文复述如下：

1. 开始的探索
   讨论者开始提到他们正在探索如何获取当前显示器的垂直刷新率。他们提到可能会尝试使用一些 API 来获取相关信息，并查看 MSDN 文档来找到解决方案。

2. 关于刷新率的初步了解
   讨论者首先提到，获取的垂直刷新率值为 0 或 1，这代表了显示硬件的默认刷新频率，这对于他们的需求并不有用。他们希望能获取到具体的刷新频率值，比如 60Hz，而不是默认的 0 或 1。

3. 列举显示器和获取信息
   讨论者尝试列举连接的显示器，打算从中找到相关的刷新率信息。他们提到，可以通过显示器的设备上下文句柄 (HDC) 来操作显示器，可能会通过调用一些函数来获取显示器的详细信息，比如 GetMonitorInfo。但他们并不确定这种方法是否有效。

4. 对 MSDN 和 Stack Overflow 的看法
   讨论者提到他们通常不完全信任 Stack Overflow 的答案，因为这些答案有时并不准确。而他们更倾向于首先参考 MSDN 文档，尽管也承认 MSDN 上的内容有时也可能出错。

5. 获取刷新率的难点
   在深入查找相关方法后，讨论者意识到获取刷新率的具体值是非常困难的。他们尝试查阅有关 GetMonitorInfo 和其他相关 API 的文档，但最终仍未能找到理想的答案。讨论者提到，操作系统提供的接口并不总是能直接给出我们想要的具体刷新率，尤其是在不同硬件和驱动程序的配合下。

6. 旧方案和直接方法
   面对这些困难，讨论者开始回想旧时代的一些方案，比如通过低级的图形接口（如 DirectDraw）来获取刷新率。他们提到，这种方法可以通过计算图形卡刷新时间来估算刷新率，但这种做法较为过时，并不符合现代需求。

7. 对现有方法的怀疑
   讨论者进一步表示，不确定目前的方法是否足够有效，尤其是在操作系统或硬件层面无法提供直接答案的情况下。他们认为如果操作系统能够像调用一个简单的接口一样返回显示器的刷新率，那将是一个理想的解决方案。但目前的情况并不是这样，操作系统没有提供一个统一且直接的方法来获取刷新率，导致开发者需要处理更多复杂的底层细节。

8. 结论和失望
   最后，讨论者表达了对当前状态的失望。他们认为，尽管刷新率的获取看起来是一个标准的功能，但实际上却涉及许多复杂的操作系统和硬件层面的问题。讨论者提到，平台层的程序员经常面临这种麻烦，并希望尽快脱离这种需要深入操作系统和硬件细节的工作。

9. 未来的计划
   尽管当前没有理想的解决方案，讨论者表示他们将继续探索，可能会回到一些老的代码和方法，或者尝试其他更直接的方式来处理这个问题。他们也提到，可能还需要更多时间来解决这个问题，或者通过直接进行一些硬件级别的操作来绕过当前的限制。

总的来说，这段对话表现出了在开发中，尤其是涉及操作系统和硬件交互时，开发者面临的挑战与复杂性。他们并未找到一个简单直接的方式来获取显示器的刷新率，而是需要依赖更复杂的底层方法和深入的技术理解。

开始实现强制视频帧率

timeBeginPeriod 是 Windows 多媒体库（WinMM）中的一个函数，用于设置系统计时器的分辨率。它主要应用于需要高精度计时的场景，比如游戏、音频播放、视频处理等。

函数定义

WINMMAPI
MMRESULT
WINAPI
timeBeginPeriod(
    _In_ UINT uPeriod
    );

参数

• uPeriod：指定计时器的分辨率（单位为毫秒）。
  例如，如果 uPeriod 为 1，则将系统计时器的分辨率设置为 1 毫秒。

返回值

• 成功返回 TIMERR_NOERROR（值为 0）。
• 如果失败，返回错误代码（例如 TIMERR_NOCANDO 表示无法更改分辨率）。

功能和作用

1. 调整计时精度：

   • 默认情况下，Windows 系统计时器的精度较低（通常为 10~15 毫秒）。
   • 调用 timeBeginPeriod 后，可以提高计时器的精度到指定的毫秒数。

2. 配合多媒体或高精度任务：

   • 高分辨率的计时对多媒体应用、实时任务非常重要。
   • 例如，配合 timeGetTime 或 Sleep 函数可以实现更高精度的时间控制。

注意事项

1. 影响系统性能：

   • 提高计时器精度会增加 CPU 的工作负担，因为系统需要更频繁地触发时钟中断。
   • 不建议不必要地将分辨率设置得过低。

2. 成对使用：

   • 在调用 timeBeginPeriod 后，应在程序结束时调用 timeEndPeriod 恢复默认设置。
   • 示例：

     timeBeginPeriod(1); // 设置计时器分辨率为 1 毫秒
     // 执行需要高精度计时的任务
     timeEndPeriod(1);   // 恢复默认分辨率
     

3. 全局影响：

   • timeBeginPeriod 会影响整个系统，而不仅限于当前进程，因此使用时需谨慎。

示例

#include <windows.h>
#include <mmsystem.h>
#include <iostream>

#pragma comment(lib, "winmm.lib")

int main() {
    // 设置计时器分辨率为 1 毫秒
    if (timeBeginPeriod(1) == TIMERR_NOERROR) {
        std::cout << "Timer resolution set to 1 ms." << std::endl;

        // 模拟一个需要高精度计时的任务
        Sleep(100); // 高精度休眠 100 毫秒

        // 恢复默认分辨率
        timeEndPeriod(1);
    } else {
        std::cerr << "Failed to set timer resolution." << std::endl;
    }

    return 0;
}

总结

timeBeginPeriod 是一个用于提升系统计时精度的重要函数，但需要在性能和需求之间权衡使用，避免对系统整体性能造成不必要的影响。

//频率30Hz 每帧基本保持再33ms

Q&A 和相关的补充

问题1. 如果我们锁定帧率，那是否意味着配置较低的电脑运行的游戏速度会比其他电脑更慢？

以下是对上述内容的详细复述：

1. 锁定帧率的疑问
   一开始提出了一个问题：如果我们锁定了帧率（frame rate），是否会导致引擎在低端电脑上运行得更慢，从而让整个游戏的速度都受到影响。具体地，如果某个玩家的电脑性能较低，无法达到目标帧率，这是否会导致游戏的整体表现下降，甚至直接运行不畅。

2. 引擎行为的解释

   • 锁定帧率并不是当前引擎的最终目标。虽然锁定帧率看起来“很整洁”（neat），但这并非是我们真正想做的事情。
   • 引擎的设计目标是运行在固定的帧率上，而不是强制性地锁定帧率。

3. 动态帧率的实现

   • 在后续的代码中，引擎将尝试动态调整目标帧率。
   • 例如，如果用户的电脑性能不足以维持每秒 30 帧的最低帧率（如 FPS = 30），系统可以将目标帧率动态降低至 15 帧每秒（FPS = 15），以适应硬件条件。
   • 在这种情况下，虽然帧率较低，但游戏的整体运行速度仍然保持正确（例如，时间同步和物理运算仍按照真实时间计算），只是每帧的显示会变得很慢。

4. 建议和争议

   • 尽管可以通过降低帧率让游戏“仍然可以运行”，但开发者提出了一种观点：与其让游戏在极低帧率下运行（例如每秒 15 帧），可能还不如直接给玩家提示，“你需要一台新电脑”。
   • 原因在于，在低于 30 帧每秒的情况下，游戏的体验可能已经接近“无法游玩”的程度，因此运行低帧率的游戏并没有太大意义。

5. 设计的关键点

   • 核心目标是让游戏以合理的速度和帧率运行，而不是强制性地锁定帧率。
   • 动态调整帧率的机制可以兼顾低端硬件，但开发者倾向于认为应以更高的硬件要求为标准，而不是牺牲游戏体验来适配极低端设备。

6. 调试与实现计划

   • 当前的代码框架中已经包含了对目标帧率调整的尝试，将会根据实际性能动态调整帧率。
   • 未来可能需要进一步完善动态帧率逻辑，以确保在不同硬件条件下仍然能提供“正确的游戏速度”和“可接受的帧率”。

7. 幽默感的表达
   最后开发者带着些许幽默感提到，与其让游戏在 15 帧每秒的情况下运行，不如直接弹出一个大提示框，告诉玩家：“你需要买一台新电脑，因为以 15 帧运行的游戏基本上是无法游玩的。”

总结

这段对话的核心围绕帧率锁定的设计哲学展开。开发者试图在性能与体验之间找到平衡：动态帧率虽然能适配低端设备，但开发者更倾向于提醒玩家升级硬件，以确保最佳游戏体验。

问题：即使你能够获取显示器的刷新率，你如何在垂直消隐（vertical blank）期间与其同步？

问题：即使你能够获取显示器的刷新率，你如何在垂直消隐（vertical blank）期间与其同步？

在这里，开发者讨论了如何处理帧同步的问题，特别是在不依赖显示器刷新率的情况下保持动画的一致性。

核心思想：

1. 灵活的帧速率
   游戏的帧速率不是固定的，而是“修正”的。开发者可以根据需要动态调整固定帧速率，使动画一致。这样即使刷新率无法精确获取，游戏仍然能够适应不同的终端设备性能。

   • 修正帧速率的意义：
     修正帧速率是为了在翻转帧（frame flipping）时保证动画一致，同时允许在必要时更改该固定速率。
   • 灵活运行帧速率：
     游戏可以运行在 60、30 或 120 帧等任何目标帧速率，具体取决于用户设备的性能。

2. 监视器刷新率同步的挑战
   即使无法直接获取显示器的刷新频率，同步的问题仍需要解决。

   • 在原型开发中，与显示器同步可能并不是优先事项。
   • DirectDraw 的历史作用：
     DirectDraw（尽管现在已被弃用）允许等待垂直消隐（vertical blank）的同步操作。如果需要，可以利用这种功能。然而，由于 DirectDraw 已被废弃，这种方法在现代开发中不常用。

3. 与显示器同步的替代方案

   • 垂直同步的影响：
     如果无法与显示器同步，可能会出现画面撕裂（tearing）现象，例如中间有一条明显的分割线。
   • 现代平台的支持：
     在最终的游戏平台上（例如使用 OpenGL 或类似的技术），可以通过设置标志（flag）实现自动同步。操作系统会处理帧同步，开发者只需将帧提交给系统，操作系统会确保与显示器同步。

4. 原型引擎的实现
   在原型引擎中，直接与显示器同步并不是首要任务。开发者可能不会专注于优化垂直同步的细节，而是优先解决动画和帧速率的一致性问题。

5. 睡眠（Sleep）功能的位置
   关于代码实现中的 Sleep 函数，有人提出疑问：它是否应该放在周围的 if 语句中，而不是 while 循环中。这关系到帧速率控制的具体实现和性能优化。

总结：

开发者讨论了帧速率修正与显示器刷新率同步的策略，提出了灵活调整帧速率以适应终端设备性能的解决方案。他们强调，在原型阶段可能不会处理复杂的同步细节，而是在最终平台上通过现代 API 自动实现垂直同步，以避免撕裂问题和性能瓶颈。

问题：sleep 函数不是应该放在外围的 if 语句中，而不是 while 循环中吗？

回答者首先表示，无论是将 sleep 函数放在外围的 if 语句中还是放在 while 循环中都可以，具体放哪里并不重要。接着，他解释了，如果将 sleep 放在 while 循环中，会有一些潜在问题。首先，他提到需要确保操作系统不会忽视 sleep 调用，因为如果 sleep 时间设置为零，操作系统可能会立即唤醒应用程序，从而造成无休止的循环，浪费计算资源。这就是为什么在 while 循环中放置 sleep 可能导致问题的原因。

然后，他指出，如果在 while 循环内调用 sleep，会让程序继续运行直到条件满足，从而避免了这种潜在的问题，因为每次循环都会重新计算等待时间。如果将 sleep 放在 while 循环外部，则可能没有足够的条件检查，从而导致 sleep 无效或行为不一致。

此外，回答者表示，这种选择会多做一次计算（检查 sleep 的毫秒值），而且可能会影响应用程序的效率，尤其是在涉及旋转锁（spin lock）时。然而，这仍然是一个可接受的方案。回答者最后总结道，不管选择哪种方式，最重要的是根据具体需求做出判断，决定最合适的代码实现。

总的来说，sleep 放在 while 循环内部或外部，主要取决于是否需要确保每次循环都有适当的条件检查和时间计算。

问题：Win32FillSoundBuffer 是否需要放在垂直同步（vsync）循环之后？

目前的状况是，声音存在问题，因为我们还没有更新它，它没有随着新的一帧更新。现在，声音是不对的。由于我们还没有进行相应的更新，声音没有在新的一帧中同步，因此它显示为错误。

我没有处理这个问题，我并不打算立即修复声音问题，因为我不希望现在就做补丁或调整。实际上，这是因为我们计划重新设计声音的计时机制。因此，现在我并不想修改它，等我们重新做声音计时时再一起处理。

关于声音部分，目前不需要考虑它，因为我们根本没有仔细查看过声音系统的实现，实际上它是完全错误的，并没有遵循我最初设计的框架。这个框架最开始的设定是，我们要按照一定的结构来处理声音，而现在它并没有做到这一点。

我们的目标是，明天开始修正声音部分的代码，并确保它与最初的框架图一致。所以，在那之前，关于声音的工作会被推迟处理。

至于现在的问题，理论上这些问题应该得到解决，因为我们正在重新设计声音的时序方式，确保它与系统的其他部分对齐。所以，不要过多关注目前存在的问题。最后，如果对声音处理有疑问，可以参考MSDN上的合成计时信息（dwmGetCompositionTimingInfo）。

问题：你能解释一下在不同线程上处理更新和渲染的优缺点吗？

潜在的好处

1. 更高的更新频率：有时候，游戏状态的更新频率可能需要比渲染的频率更高。例如，在物理引擎中，可能需要每秒进行多次更新，但游戏的帧率可能只有30帧每秒。在这种情况下，物理更新比渲染更新更频繁，这就需要通过多线程来分担任务。通过使用独立的线程来处理物理计算和渲染，可以避免物理模拟的滞后，确保游戏状态在每帧内都得到精确的更新。

2. 更细粒度的任务分配：如果某些更新任务非常细致，可能需要比渲染操作更频繁地处理。这种情况下，物理计算等可以在不同线程上处理，从而减少渲染过程中的延迟。例如，假设物理更新需要比游戏更新更频繁地执行，可以通过在单独的线程中执行物理更新，并将渲染保持在较低的频率上，从而优化性能。

3. 避免帧率瓶颈：当更新和渲染操作在同一线程上时，可能会因为帧率限制而导致性能瓶颈。通过将更新和渲染分开，程序可以在一个线程中运行复杂的游戏逻辑和物理模拟，而在另一个线程中渲染画面，这样有助于分散负载。

潜在的缺点

1. 增加复杂性：引入多线程意味着需要管理更多的同步和线程安全问题。确保数据的一致性和避免资源冲突需要额外的精力。例如，物理引擎和渲染线程之间的资源共享（如模型、纹理等）需要有效的同步机制，避免竞争条件和死锁问题。

2. 线程管理开销：创建和维护额外的线程会增加程序的开销，尤其是在涉及到频繁上下文切换时。这种额外的开销可能会导致性能下降，尤其是在多核处理器的环境中。

3. 调试和测试复杂性：多线程程序通常更难调试，特别是在涉及到时间步长和渲染同步时。如果物理更新和渲染更新不同步，可能会导致可视化问题或物理状态不一致，这些问题在开发过程中难以复现和修复。

4. 避免过度优化：在没有明确的性能需求时，过度优化多线程更新和渲染可能带来更多复杂性，而没有带来明显的性能提升。在某些简单的应用中，使用单线程可能更加高效和易于管理。

结论

尽管在某些情况下使用独立线程处理更新和渲染可以带来性能上的优化，但它也会显著增加程序的复杂性。程序员需要权衡复杂性和性能之间的关系，并确保在实现多线程时有明确的需求和目标。

问题：如何调整内存管理以适应内存有限的设备？

在内存有限的设备上调整内存管理需要采取多种优化策略，以确保内存的有效利用。以下是一些常见的调整方法：

1. 优化内存使用

• 选择高效的数据结构：使用适合于资源受限设备的数据结构，尽量减少内存占用。例如，使用紧凑的结构体或数组，避免不必要的冗余数据。
• 内存池：通过内存池来管理内存，避免频繁的动态分配和释放内存。内存池可以预先分配固定大小的内存块，并在程序中重复使用这些内存，减少碎片化和管理开销。

2. 按需加载（懒加载）

• 延迟加载资源：仅在需要时加载资源，而不是在程序启动时一次性加载所有资源。例如，图像、音频或其他大文件可以按需加载，而不是一次性加载所有数据。
• 分块加载：将大型资源分割成较小的块，只加载当前需要的部分。例如，对于大地图或长列表，按区域或段加载数据，而不是加载整个数据集。

3. 共享内存

• 内存映射文件：利用操作系统提供的内存映射机制，将文件内容映射到内存中，避免将整个文件加载到内存中。这样，文件内容只有在需要时才会加载到内存。
• 内存共享：对于多个进程或线程之间共享的数据，可以使用共享内存区域，减少内存的重复分配和存储。

4. 内存优化算法

• 压缩数据：通过压缩存储数据，尤其是对于大型文本、图像等，可以显著减少内存占用。在需要使用时再进行解压缩。
• 数据精度降低：根据需求，减少数据的精度来降低内存使用。例如，对于浮点数据，可以考虑使用较低精度的浮点类型，或者将数据转换为整数类型。

5. 垃圾回收与内存清理

• 定期清理内存：及时释放不再使用的内存，尤其是在嵌入式设备或资源有限的设备上。在使用完某些资源后，可以显式调用内存释放函数，避免内存泄漏。
• 手动管理内存：在一些低级编程语言（如C/C++）中，需要开发者手动管理内存的分配和释放，确保程序不占用不必要的内存。

6. 使用硬件特性

• 硬件加速：一些设备提供硬件加速功能（如GPU、DSP等），可以利用这些硬件来处理计算密集型任务，减少主内存的负担。
• 嵌入式系统优化：在嵌入式设备上，往往有更严格的内存限制，开发者可以根据具体的硬件特性进行内存管理的调整，例如通过直接操作硬件寄存器或使用特定的操作系统功能来优化内存。

通过这些方法，可以有效地管理有限内存资源，确保设备能够高效运行，同时尽量减少内存使用和系统开销。

问题：由于 sleep，我们不会错过帧率吗？

这段内容探讨了在帧率控制过程中，由于使用 sleep 函数导致帧率可能丢失的问题。具体而言，讨论的要点包括以下几点：

1. 截断精度问题：
   当你在进行帧率控制时，可能会遇到精度问题。例如，在进行时间计算时，如果将睡眠时间截断到某一固定的毫秒数（例如 10 毫秒），可能会导致微小的误差。比如，当你将 10.3 毫秒截断为 10 毫秒时，剩下的 0.3 毫秒时间就变成了浪费时间（例如在自旋锁上等待）。

2. 误差如何影响帧率：
   这些误差虽然看似微不足道，但却可能对帧率产生影响。即使是 1 毫秒的误差，在高帧率要求下可能会产生累计效应。尤其在物理更新和渲染更新之间需要精细同步时，任何小的误差都可能造成帧率不稳定。

3. 使用 sleep 控制帧率的有效性：
   讨论者认为，虽然 sleep 方法能帮助控制帧率，但它也存在不确定性。尽管我们可以通过断言和其他手段确保不超过目标帧率，但由于操作系统调度和精度问题，帧率仍可能受到影响。尤其是在不同的操作系统或环境中，sleep 的精度可能有所不同，这使得程序的表现存在变数。

4. 物理动画与图形帧率的分离：
   讨论还涉及到是否可以在不修正图形帧速率的情况下修正物理动画帧速率。基本观点是，物理动画可以单独进行更新，并且更新频率可以与渲染帧率不同步。通过将物理更新放在更高频率的循环中，可以使物理动画更精确，而不影响图形渲染的频率。

5. 关于帧同步：
   提到在一些情况下，为了避免帧丢失，可能需要在每次帧更新后验证当前的时间，确保睡眠时间不超过设定的目标帧时间。这可以通过在睡眠后检查时间来实现，避免过度延迟导致的帧率下降。

6. 操作系统依赖性：
   讨论还提到，帧同步和 sleep 行为在不同操作系统中可能会有所不同。在 Windows 上，特别是使用了 DWM（桌面窗口管理器）进行合成的情况下，应该不会出现画面撕裂，尽管在旧版操作系统（如 Windows XP）中，可能存在性能问题。

总结来说，这段讨论主要集中在如何处理 sleep 函数对帧率控制的影响，并探讨了如何通过精确控制物理更新与渲染更新的同步来解决可能出现的帧率问题。此外，还讨论了在不同的操作系统环境下，sleep 的效果可能不同，从而影响最终的帧率稳定性。

问题：你能在不修复丢帧问题的情况下修正物理动画的帧率吗？

上面的内容讨论了物理动画和帧率的问题，特别是如何避免因丢帧导致的错误表现。关键点可以总结如下：

1. 错过帧的影响：

   • 如果错过了一个帧，并且不做特别处理，渲染的结果仍然会显示错误。例如，运行物理引擎时，物理时间计算与实际渲染时间不同步，导致渲染的结果与预期不符。

2. 处理丢帧：

   • 即使错过了一个帧，也不需要多次运行物理引擎来弥补这一帧。因为物理引擎允许较大的时间步长，因此它会在下一个帧中正确地更新物理状态，尽量赶上目标位置。

3. 常见错误做法：

   • 一些开发者会在错过帧后，尝试通过将时间增加一定值（例如，增加额外的毫秒数）来补偿。然而，这种做法是错误的。因为这样不仅会导致时间上的偏差，还可能在后续帧中引入更大的错误，使得物理和渲染的时间完全不同步。

4. 正确的做法：

   • 正确的方法是，根据每帧的实际情况来计算物理更新所需的时间，而不是使用上一个帧的时间来推算当前帧的时间。每一帧的时间应根据当前的实际状态来动态计算。
   • 你需要确保每帧更新的时间是准确的，而不是盲目地依赖前一帧的时间信息，因为每一帧的情况可能是不同的，可能会有一些不寻常的情况。

5. 不使用最后一帧的时间：

   • 绝不能仅仅依赖上一个帧的时间来决定当前帧的时间，因为它不能正确反映当前帧的真实时间。如果依赖这种方式，游戏可能会导致错误的帧时间计算，产生不正确的渲染效果。

6. 物理更新与渲染帧分离：

   • 物理引擎和图形渲染帧需要分开处理，不能简单地通过将时间加到上一帧来调整物理状态。每帧的物理更新应该是独立计算的，而不受前一帧的影响。

总结来说，正确的做法是独立计算每一帧的物理更新时间，而不是通过加上上一帧的时间来进行补偿。开发者需要注意，每一帧的物理和渲染时间应根据当前的状态独立计算，而不是盲目地将上一帧的时间转发到当前帧，这样才能避免错误的帧时间计算，确保游戏表现的正确性。

这段对话涉及到游戏编程中的一些关键概念，特别是关于物理引擎的时间更新和帧率同步的问题。

首先，讨论的核心问题是如何处理固定和可变时间步长的物理更新。在一个游戏中，帧率（比如每秒30帧）和物理更新（例如模拟每个物体的位置）之间必须有良好的同步。然而，由于硬件和渲染的限制，常常会遇到“丢帧”的问题，也就是说游戏物理更新的时间超出了预期的时间步长。

主要讨论的要点：

1. 丢帧问题：

   • 如果某一帧渲染时间超出了预期（例如，你应该在16毫秒内渲染一帧，但由于某些原因，实际渲染时间延长到了30毫秒），你可能会错过渲染更新。
   • 有些开发者会简单地做出补偿，假设 missed frames 只是简单地延长帧时间，但这种做法并不总是正确的。实际上，这可能会导致更新与预期不符。

2. 物理时间的更新：

   • 游戏物理的更新通常应该独立于渲染的帧时间，而是依赖于实际经过的时间（例如，每16毫秒更新一次）。如果渲染时间过长，物理时间更新仍然可以继续，但不应基于最后一帧的时间来推算下一帧。
   • 这样做的目的是确保无论帧率波动如何，游戏物理的运行都保持一致性。例如，物理引擎应该通过不断前进一定时间步长来推进世界，而不是将物理更新时间与上次渲染帧的时间做直接的关联。

3. 刷新率和显示器同步：

   • 在显示器刷新时机上，需要注意，不应该在刷新点之前填充屏幕缓冲区，直到刷新正确发生。有些开发者会尝试“填充屏幕缓冲区”，但这并不总是适用，因为你无法准确预测刷新发生的确切时刻。
   • 关键是要确保在刷新点发生之前，物理和渲染都已经适当同步，并且没有撕裂现象。

4. 可变时间步长：

   • 如果游戏采用可变时间步长的方式更新物理状态，物理更新可能会有不同的时间间隔。这种方式可以确保在不同平台上，物理引擎的表现尽可能一致。
   • 然而，使用这种方法时需要小心，可能会引发输入延迟，影响用户体验。因为用户的输入可能会与物理时间不完全同步，从而导致不必要的延迟。

5. 不可预见的翻转时机：

   • 游戏中的“翻转”指的是图形和物理状态的更新过程，可能是在渲染完成后，等待下一次刷新周期来切换图像。开发者不能总是精确预测翻转的时机，因此需要采取一些策略来避免因时间误差而导致图像撕裂。

6. 理想的更新策略：

   • 解决这个问题的理想方式是计算出每一帧应该花费的时间，并根据此时间来更新物理世界，而不是依赖上一帧的时间。这种方式确保了每个帧都有足够的时间进行适当的物理计算。

总的来说，讨论中的关键观点是：不要盲目依赖上一帧的时间来决定下一帧的物理更新，而是要确保每个帧都能准确计算其物理状态。游戏开发中的帧率同步和物理时间更新是一个复杂的问题，需要精确的控制和合理的时间计算，避免出现图像撕裂和输入延迟等负面影响。