仓库:https://gitee.com/mrxiao_com/2d_game_2
查看我们上次停留的位置，看看 PixelsToMeters 仍然是如何进行的
目标是通过不使用引擎和库的方式，手动编写整个游戏代码，以便记录和教育开发过程中涉及的每一个细节。这种做法有两个主要原因：其一是为了教育，文档化游戏开发的全过程，确保所有的代码都能作为参考，避免任何东西隐藏在引擎或库的封装下；其二是因为这样可以自由地进行实验和修改，探索各种编程方式，帮助更好地理解整个代码库。
在上次的开发中，重点是从主游戏代码中去除与像素相关的部分，将所有与像素相关的内容移交给渲染器。游戏代码现在主要处理世界单位，并且只会使用这种单位，这使得渲染部分成为唯一需要处理像素的地方。这样做的一个主要好处是，游戏代码和渲染部分是解耦的，渲染部分可以独立于分辨率进行调整，而游戏代码则不需要为不同的分辨率做任何更改。
接下来，需要进一步清理和优化与像素相关的部分。尤其是在地面缓冲区的处理上，仍然存在一些问题，主要是因为地面缓冲区仍在使用像素单位而非世界单位。开发者希望通过对代码进行搜索和检查，找出所有依赖像素到米（PixelsToMeters）转换的地方，并去除这些依赖，使得所有代码能够在不涉及像素的情况下正常工作。最终目标是让游戏引擎仅通过渲染部分处理像素问题，游戏逻辑则完全使用世界单位，从而实现分辨率无关的设计。
让渲染器负责告诉我们屏幕的尺寸
接下来，讨论的内容主要集中在如何处理屏幕宽度和高度（以米为单位）的计算。目标是将所有与像素相关的计算从游戏代码中去除，使渲染部分成为唯一处理像素的地方。这样，游戏代码可以完全不关心像素，所有的单位都应当是独立的，渲染部分则根据分辨率和其他因素来决定最终的像素值。
具体的做法是，引入一个新的函数来获取屏幕尺寸，这个函数会返回当前可视区域的矩形（Rectangle）。为了实现这个，渲染部分将负责返回与相机相关的尺寸信息。通过一个函数，能够计算出在特定深度（z 值）下，相机所能看到的区域大小。这种方法可以确保游戏代码无需考虑具体的像素转换，只需要知道屏幕上区域的尺寸，而这些尺寸可以通过渲染器计算出来。
函数的设计考虑了相机的深度（距离相机的 z 值），并通过不同的输入参数（例如，默认的相机距离）来决定返回的矩形尺寸。通过这种方式，渲染部分可以灵活地调整相机视角，而不需要修改游戏代码的核心逻辑。最终目标是将像素处理的所有责任都集中在渲染器中，确保游戏逻辑始终使用世界坐标单位，而非依赖像素。这样，不论分辨率如何变化，游戏代码都不需要做出任何调整。
此外，讨论还涉及了如何更清晰地分离代码逻辑，避免在游戏逻辑中直接涉及像素计算，确保游戏引擎的模块化和独立性。
黑板：Y 轴的视场
在处理视场与相机距离的问题时，首先需要明确相机与世界的关系，假设相机是俯视世界，z 轴指向上方。随着与相机距离的增加，视场的大小也会增加。也就是说，距离相机越远，能看到的区域就越大。这是一个透视问题，类似于人眼看到远处的物体变小，近处的物体变大。
为了让数学计算更加明确，考虑在一个特定的距离（比如默认的目标距离）下，定义一个明确的可视区域（矩形区域）。这个矩形可以有已知的高度和宽度，或者宽度可以根据需要调整，比如让高度保持固定，宽度根据比例扩展。也可以根据需求添加"黑边"或者"信箱式"效果，这些是艺术上的决定，不涉及数学计算。
具体来说，可以在某个目标距离 d 上，定义可视区域的 y 方向长度（垂直方向），这可以看作是一个类似视场角（field of view）的概念。此时，视场的大小将直接与该距离相关，并且能够确保无论屏幕分辨率或长宽比如何变化，游戏中始终会显示一个已知的垂直视场，从而避免像素与屏幕分辨率相关的影响。
这种方法的核心是确保渲染和游戏逻辑分离，不依赖于屏幕像素的变动，保持一个稳定的数学模型来计算视场大小，确保不论屏幕尺寸如何变化，游戏代码始终处理的是固定的、基于物理单位的视场。
将相机参数放入 render_group
在处理相机投影和视场时，首先定义了焦距和相机到目标的距离，这两个参数将决定投影的结果。通过这些参数可以推导出其他的视场信息，因此，计划将这两个参数从现有的函数中提取出来，并将其放入渲染模块作为相机参数来初始化。
这些相机参数主要用于控制视场的大小。焦距和相机到目标的距离共同决定了视野的范围。例如，调整焦距或相机与目标的距离，可以改变视野的大小，从而影响视场的宽度和高度。为了简化管理，相机的焦距和距离将在初始化时指定，并在渲染过程中使用。
接下来，将焦距和相机距离从渲染函数中提取出来，并确保通过渲染模块进行访问。然后，计算与目标的投影相关的参数，包括相机的矩形范围，这些计算将基于相机的实际距离和焦距来完成。
此外，计算过程还涉及到显示器的纵横比。通过了解显示器的纵横比，可以利用投影方程来确定投影后的 x 和 y 值。计算过程将通过一个公式来实现，其中包括从相机到目标的距离和焦距的关系。需要特别注意的是，相机的矩形范围将随着相机的移动和焦距的变化而改变，影响到最终的显示效果。
通过这些计算，最终能够确定如何根据屏幕的尺寸和显示器的纵横比来调整视场的投影，从而实现与目标的精准匹配。
黑板：根据投影坐标 (ProjectedXY) 计算 RawXY 距离
在进行投影时，使用的是类似的三角形关系。当前的目标是计算屏幕外部的投影坐标，也就是屏幕的边缘在特定距离下的投影值。
我们首先定义了相机的位置，并且考虑到显示器的距离与焦距。焦距用于描述相机到显示器的距离。
接下来，要做的是计算在不同的距离下，如何得到投影的坐标。通过某种反向推导，给定某个假设的距离，计算出当显示器的边缘位置被投影到相机视野中的坐标。
目标是弄清楚，在这个新的假设距离下，显示器的最远边缘位置应该如何与投影坐标对应。
计算 RawXY
这里的方程用于计算逆投影。我们希望通过给定屏幕上的投影坐标（如显示器角落的投影坐标），反向计算出对应的世界坐标。
具体步骤是，首先将方程两边都除以一个项，然后将焦距从方程中消除，最后通过这个方程就可以得到从屏幕坐标反推到世界坐标的方法。
反向投影方程使得从屏幕坐标计算世界坐标变得可能。可以将这个过程封装成一个函数，类似于 "Unproject" 的函数，接收投影后的坐标（x, y），并返回对应的世界坐标。虽然这个过程在二维环境下较为简单，但在实际游戏中通常会稍微复杂一些，尤其是在三维环境下。
通过这个函数，可以指定一个屏幕上的点，得到该点在世界坐标中的实际位置，前提是已知目标点与相机的距离。这种计算方式是游戏引擎中的常见操作，可以用来在不同深度下，计算屏幕上某个点的对应世界坐标。
为了准确执行反投影，需要传入焦距信息，因为没有焦距，就无法进行计算。因此，该函数也需要传入焦距的参数，以便正确地计算投影。
了解在投影坐标 (ProjectedXY) 中填充的内容
目前的任务是确定如何根据屏幕的投影坐标计算出实际的物理尺寸。我们知道，所有的计算都是基于米（meter）为单位进行的，所以需要将像素转换为米。在投影之后，我们需要通过像素与米的转换比例来扩大结果，确保最终计算的是物理尺寸，而不仅仅是屏幕坐标。
关键在于需要决定屏幕的尺寸（宽度和高度）。要实现这一点，我们需要知道从屏幕中心到屏幕边缘的距离，也就是屏幕的物理尺寸。根据这些信息，可以推算出一个点在物理世界中的位置。
具体来说，首先，我们需要使用一个投影方程计算出屏幕上的投影坐标（x，y）。接着，将这些坐标转化为物理尺寸，换算成米。为了实现这一点，我们需要知道每个像素所代表的物理尺寸（即像素到米的转换比例）。
在此基础上，通过将投影坐标与像素到米的转换比例结合，能够获得对应的世界坐标。通过这种方式，我们可以计算出每个像素对应的实际世界位置，从而确保最终图形渲染与物理世界之间的一致性。
此外，还涉及到使用屏幕的实际分辨率来设定像素到米的转换比例。如果需要，可以进一步优化这个过程，确保屏幕尺寸固定，避免其他因素干扰计算。
总结起来，目标是通过已知的投影坐标和像素到米的转换比例，计算出屏幕上某个点的世界坐标，确保渲染和实际世界的正确对应。
进入并查看我们得到的尺寸
目前的任务是检查当前计算中的尺寸值，并验证它们是否正确。原先的屏幕尺寸和PixelsToMeters的转换值已经不再适用，因为引入了投影计算后，这些转换比例已经发生了变化。因此，先前的尺寸和比例数据已经不再准确。
在代码中，屏幕的尺寸为22米宽、12米高，这在实际应用中看起来是合理的，表示一个房间的尺寸。接下来，目标是通过新的颜色和渲染方式，查看当前的尺寸是否能够准确反映在渲染过程中。
在实现过程中，调用了GetCameraRectangleAtTarget函数，传入了目标缓冲区（DrawBuffer）以及像素到米的转换比例。目标是查看当前在摄像机距离为5米时，渲染结果会怎样。实际测试中，初始化的投影坐标为14, 9，看起来合理。然后，通过计算，得到了与默认尺寸比较的结果，发现其尺寸略小于预期，且输出结果的尺寸是预计尺寸的两倍，符合期望。
总结来说，目前的测试显示，摄像机和屏幕的尺寸已经较为合理，但仍需进一步调整和验证，尤其是在投影转换与实际物理尺寸的对应上。
在游戏中查看效果
目前的测试结果看起来比较合适。房间的尺寸是28米宽，实际渲染出来的宽度大约是18米，能够看到从一侧到另一侧还有一定的空间，整体看起来很合理。
尽管在没有开启优化的情况下，性能比较慢，但重新加载代码并启用编译器优化后，性能应该会有所提升，这是一个可以利用的优点。
从尺寸上看，这些值是符合预期的，测试结果看起来正确。因此，整体上，当前的实现和尺寸都在合理范围内。
继续推进，逐步优化
目前存在的主要问题是，屏幕尺寸显得过于庞大，尤其是在使用当前焦距的情况下，似乎没有太多道理。应该能够通过减少焦距来减小显示器的尺寸，因此现有的"像素到米"的转换可能会限制了我们对显示器尺寸的控制，使得我们还在不自觉地思考像素，而不是专注于现实世界的单位。
当前的问题出现在使用"像素到米"的转换时，这个转换本应该是用于屏幕的像素尺寸，而不是用于世界空间的像素。这样思考会导致我们在进行转换时，依然受到像素单位的约束，因此需要重新调整，确保转换是基于显示器上的实际像素，而非在世界坐标系统中应用像素尺度。这将帮助我们脱离对像素的依赖，更好地处理屏幕和世界空间之间的关系。
在显示器上引入 MetersToPixels
在讨论如何确定显示器的尺寸时，首先需要考虑显示器的实际物理尺寸。例如，假设显示器为30英寸，首先将其转换为米，计算显示器对角线的长度。接下来，需要确认显示器的实际宽度和高度，通常这些尺寸与分辨率有关，屏幕的分辨率决定了显示器上每米所对应的像素数。
"15.6 英寸"通常是指显示器或屏幕的对角线长度，单位是英寸。1 英寸大约等于 2.54 厘米。
例如，假设一个15.6英寸显示器的宽度大约是0.396米，如果显示器的分辨率为2560像素，则每米的像素数为2560除以0.396，即每米大约对应6465像素左右。
接下来，需要调整渲染组的设置，确保其与显示器的像素分辨率匹配。为了正确计算渲染效果，应该在渲染时使用这个像素比例。特别是，在渲染时需要通过焦距来调整显示器的显示效果。如果焦距过大，显示器的尺寸会显得不合适，因此需要将焦距调整到一个合理的值，假设为0.3米，这样就能模拟出一个正常的显示器视距，通常这个距离是用户与30英寸显示器之间的典型视距。
最后，在分配渲染器时，应该传入这些调整后的参数，确保渲染时的显示尺寸与实际屏幕尺寸一致。
TODO 我们如何控制地面块的分辨率？
对于地面块的分辨率，目前情况有些复杂，因为并不清楚确切的需求。这部分的工作还需要进一步明确，如何控制地面块的分辨率将是接下来的一个重要任务。这是一个需要解决的关键问题，因为它涉及到如何处理和调整地面块的大小和分辨率。当前的做法是暂时做出一些假设，并在后续逐步调整，直到找到最合适的方式。
将 DrawBuffer->Width 和 Height 传递给 AllocateRenderGroup，并在游戏中查看
在分配渲染组时，可以传入宽度和高度值。然而，目前这个方法还不完全正确，因为投影值可能会被弄乱。主要问题是还没有更新一些关键的参数，尤其是焦距。焦距值此时可能完全不正确，因此需要进一步调整这些参数，确保它们与渲染组的设置相匹配。
刷新焦距 (FocalLength)
焦距的设置应该比之前小得多，它应该大致等于人们坐在显示器前的距离。假设一个人坐在显示器前大约两英尺的地方，相当于大约0.6米，这个值符合实际情况，也和之前调节的数值差不多。之前的错误在于，使用了错误的"米到像素"的转换值，因为那时我们在假设的显示器表面上进行投影，需要思考的是在显示器上每米应该是多少像素，而不是游戏世界中的单位。因此，现在所有的数值都基于现实世界的参数，比如焦距就是人们坐在显示器前的实际距离，显示器的宽度也是实际值。
现在，我们的设置已经转换成了一个现实世界的场景，所有的参数都是真实的数值。唯一需要调整的就是相机的高度，控制相机距离目标的高低，这样就能模拟一个正常用户的视角。当相机的高度调整合适时，画面会呈现出真实的透视效果，仿佛物体就在显示器屏幕后面。通过调整这个值，就能控制画面视距，模拟不同的观看距离。
调整代码
在这段过程中，首先可以清除不再需要的代码部分，因为现在这些值已经直接在渲染组中指定，无需再通过额外的参数传递。接下来，为了简化存储和访问过程，可以将一些相关的值（例如投影的x和y值）存储在渲染组内。这样做可以通过存储显示器的半尺寸来将其与坐标系相结合，从而更加方便地访问这些数据。
在代码实现中，可以将像素到米的转换简化为一个简单的公式，使用1/Result->MetersToPixels来表示转换过程。这个步骤帮助简化了原本较为复杂的转换计算过程，同时确保了不再需要通过其他多余的计算或值来传递这些信息。
总体来说，这一过程的核心目的是通过整理和简化数据存储结构，使得在后续的使用中能够更加高效和清晰地管理与显示相关的参数。
在游戏中查看效果，并引入验证计算的方法
在这段过程中，主要的目标是验证计算得到的矩形边界是否正确。为了做到这一点，需要将计算得到的屏幕矩形（即摄像机边界矩形）可视化。通过这样做，可以确保矩形的范围符合预期，进而确保其他相关功能的正常运行。
首先，将屏幕矩形绘制出来，以便直观地查看它的实际大小和位置。通过观察这个矩形是否精确对应屏幕的边界，可以确认计算的准确性。如果矩形与屏幕的实际大小不匹配，说明存在问题，进而需要对代码进行调试修复。
此外，在过程中还提到了可能的调试方式，如果矩形过小导致没有实体被引入到视野区域，也能够通过这种方式发现问题。通过这些验证步骤，可以确保代码的准确性和有效性。
绘制屏幕边界 (ScreenBounds)
在这段过程中，首先进行了矩形的绘制，目的是为了验证计算得到的屏幕边界是否准确。通过绘制矩形，可以直观地看到矩形的大小和位置，确保其与屏幕的实际尺寸一致。
具体操作是通过计算屏幕矩形的维度，并绘制一个明亮的黄色矩形，以便清楚地看到它在屏幕上的位置。为了得到矩形的维度，使用了矩形的最大角和最小角来计算其宽度和高度。通过这种方式，验证了计算结果是正确的，矩形确实覆盖了正确的区域。
完成这些后，可以确认代码已经正确地计算并展示了屏幕边界，从而确保了后续的功能实现没有问题。这也为进一步的开发提供了可靠的基础。
引入调试相机 (DebugCamera) 的概念
如何查看实体是否进出活跃区域。为了实现这一点，需要让实体能够在屏幕上显示出来，而不是被遮挡或超出视野范围。一个方法是调整摄像机的视角和距离，但这种方法可能会导致不想要的效果，特别是当通过调整摄像机距离来显示所有实体时，可能会拉进所有实体，导致显示内容超出预期。
为了避免这种情况，引入了一个调试模式，在该模式下可以使用一个调试摄像机，这个摄像机的设置不同于游戏的实际摄像机。调试摄像机会有更大的视距，允许观察到更多的区域，而实际的游戏摄像机则保持游戏中的常规视角。这样做的目的是能够同时观察到屏幕尺寸和实体的动态，同时保证游戏的正常操作。
具体实现时，首先将游戏中的摄像机和调试摄像机分开，保持两个独立的摄像机设置。通过设置调试摄像机的视距，使得可以在调试过程中查看更广泛的区域，而游戏摄像机则保持不变。最终，当进行渲染时，使用适当的摄像机进行显示，确保调试和正常渲染都能正确进行。
通过这种方式，可以在调试过程中灵活地观察实体的变化，同时不会影响游戏的实际运行状态。
在游戏中查看效果
在这个过程中，调整了摄像机的设置后，可以更清晰地看到实体在世界中的位置，并观察到它们是否进出相同的区域。通过这个视角，发现了一个潜在的 bug：实体在 x 轴方向上正常进出区域，但在 y 轴方向上却没有任何变化。这个问题虽然明显，但通过调试摄像机与常规摄像机的简单区别，可以非常方便地发现和定位错误。
这种方法让错误变得更容易追踪，因为通过切换摄像机视角，能够更直观地看到问题发生的具体位置。接下来，计划花点时间检查 y 轴方向上出现问题的原因，尽管时间有限，但仍然希望能快速定位到这个 bug。
调查为什么实体没有根据 Y 值进出 SimRegion
在处理屏幕边界时，将其映射到摄像机的范围并进行扩展，增加了 z 轴的范围。然后将摄像机的范围映射到区域空间。这些步骤包括扩大 x 和 y 轴的半径至15米，并将边界传递到同一区域进行处理。检查了半径的设置，确认没有问题，并且最大半径仍然有效。
接下来，为了更好地理解问题，决定绘制这些边界，以便清楚地看到为什么会出现不同的行为。这一步骤是为了更直观地观察边界和区域的处理情况，确保一切按预期工作。
绘制 CameraBoundsInMeters、SimBounds 和 SimRegion->Bounds
在这个步骤中，决定绘制多个边界以便进行可视化调试。首先，将屏幕边界、摄像机的米制边界以及更新后的边界以不同的颜色进行绘制。具体操作包括：
- 绘制屏幕边界。
- 绘制摄像机的米制边界。
- 绘制已更新的边界。
每个边界使用不同的颜色进行区分，例如将屏幕边界绘制为亮黄色，摄像机边界绘制为白色，更新后的边界则使用品红色（magenta）。这些绘制步骤帮助观察和分析不同边界在场景中的表现，便于识别潜在的问题或错误。
《Too Many Rects》
在这个步骤中，出现了太多矩形（rectangles）的问题，可能是因为绘制的边界过多。为了调整这一问题，决定将这些矩形视作三维空间中的物体，因此需要将其坐标从二维（x, y）转为三维。接下来，为了使矩形的尺寸能够正确显示，必须确保 GetDim 调用能够在这两个维度（x 和 y）上正常工作。由于时间限制，这将是最终要完成的任务之一。
查看所有内容，开始调查为什么实体没有按预期进入 SimRegion->Bounds
看起来问题并不是bug，而是因为视野范围显示得更远了一些。虽然不完全确定，但从当前情况来看，似乎并没有明显的bug。在检查边界时，发现"SimBounds"是一样的，而"SimRegion->Bounds"则有点奇怪。看起来它正在将物体拉入视野范围，但并没有扩展到预期的区域，这可能是因为只使用了"updated all bounds"来拉入物体。可能确实存在一些问题，但还不完全确定。
接着观察到在碰撞检测中，"TotalVolume SimRegion->Bound"出现了问题，它似乎没有完全扩展到紫色区域，尽管理论上应该是如此。可能的原因是当前的实体可能位于较高的层级，而碰撞范围应该覆盖的是较低的层级。虽然这看起来有些不对劲，但也可能只是因为位置上有些偏差。
MetersToPixels 值是否需要考虑显示器的像素密度？
关于"meters to pixels"转换是否应该考虑显示器的像素密度，答案是：它确实已经考虑了显示器的像素密度。至于是否应该考虑显示器的实际物理大小，答案是否定的，因为除非我们知道用户坐得多远，否则物理大小对转换值的影响并不大。这个问题虽然合理，但实际情况是，这种处理方式已经足够满足需求，接下来会详细解释为什么是这样做的。
黑板：我们目前的参数化方式
目前在处理参数化时，主要是通过设置合理的虚拟场景来控制视角和比例。核心问题是要设定合理的相机与显示器的距离以及显示器的大小。虽然用户实际使用的设备和坐标设置可能各不相同，但只要选择一个典型的设备配置，比例和透视会大致正确。
目前，设置的参数并不需要基于用户的真实环境，只要选取一个合适的虚拟设置，就可以大致模拟用户的观看体验。例如，如果用户坐得很近，使用较小的显示器和短的距离，这与坐得较远、使用较大电视的场景其实只是规模上的差异。通过这些设置来确保视角的正确性和画面呈现。
对于"屏幕分辨率"和"物理尺寸"问题，并不需要非常精确地模拟现实环境，只要设置一个合理的虚拟参数即可。屏幕分辨率的变化会自动影响投影的大小，这是通过结构化的方程式来实现的，确保在分辨率变化时，物体的显示大小按比例增加。
因此，监视器的分辨率密度变化并不需要进行修正，因为这正是我们希望的结果：分辨率越高，图像显示的像素数量越多，图像就会更清晰。在设计时，重要的是通过合理设置相机的焦距和显示器的宽度，确保一个普适的比例关系，这样就不再需要关心实际显示器的物理尺寸和用户的坐姿距离。
最后，分辨率的变化将自动调节绘制图像的大小，使得绘制结果在不同分辨率下都能够保持一致的比例和清晰度。这种方法确保了分辨率的独立性，不需要特别修正其变化。
确定相机应该垂直向下看向各个层级吗？如果相机角度稍微倾斜，透视艺术效果会更好吗？
关于相机的角度问题，目的是为了确保游戏中的运动表现符合预期。在这里，相机被设置为垂直向下观察，而不是倾斜的角度。这是因为不希望玩家在游戏中体验到背景和前景的运动速率差异。如果相机倾斜，背景中的物体会移动得比前景中的物体慢，从而影响游戏的平衡感。
通过保持相机垂直向下，可以确保玩家在游戏中的二维平面上进行的每一次移动都与视觉上的距离变化一致，不会出现远处物体运动较慢的现象。这种设计有助于玩家更好地感知游戏中的动作和空间关系。
能不能把 U 和 V 加入 v2？
可以将 u 和 v 这两个变量拆开并分别进行处理。可以将其分别赋值给不同的变量，以便后续使用。例如，可以将它们赋值为 w，这样就可以更方便地进行操作。如果需要，也可以直接在代码中声明变量，比如直接将 u 和 v 作为新的变量来处理。此外，也可以对其他部分进行类似的调整，如将其命名为 movie 或其他合适的标识符。这些调整有助于简化代码结构并提高可读性。
黑板：关于 VR 头显的重要非笑话事项
虽然前面的讨论看似是开玩笑，但其中确实蕴含着一个非常重要的观点。在创建真正沉浸式的3D体验时，必须考虑许多精确的参数。例如，如何确定用户距离屏幕的实际距离，如何调整视角等，这些对于创建如虚拟现实（VR）或增强现实（AR）头戴显示器（HMD）这样的设备至关重要。如果这些值不准确，用户会感到不适。
然而，目前大多数现代设备并不会提供这些准确的物理参数，也没有进行校准，导致无法根据用户与显示器之间的距离进行合适的变换。这就像是VR设备所面临的挑战，需要非常精确的值来确保用户体验舒适。在VR和AR头戴显示器的SDK中，通常会提供这些参数：从眼睛到镜头的距离、镜头到屏幕的距离、畸变程度、双眼偏移量等，这些信息可以直接用于计算正确的投影效果，确保设备的显示效果精确无误。
这种方式和我们之前讨论的原理类似，利用真实世界的单位来计算，从而实现精确的3D投影。而一旦使用这些SDK，便需要非常准确地调整这些值，无法再进行任何随意的调整。这也展示了头戴显示器SDK是如何处理这些问题，确保在虚拟现实体验中每个参数都精确到位。
"real32" 是否模糊不清，因为它既可以是浮点数也可以是定点数？
在处理"三维实数"（real）时，确实存在歧义，因为它可以是浮动点数（floating point）或定点数（fixed point）。然而，实际上，是否使用浮动点数或定点数并不那么重要。在代码中，通常使用"real32"来表示一个32位的实数值，但对于其内部表示方式并不关心。即使在某些情况下，底层实现选择了不同于浮动点数的表示方法，这也是可以接受的。这种灵活性意味着，尽管有歧义，但实际上并不影响实际应用。
更高的缩放级别下不平滑的移动是因为没有优化，还是某种亚像素平滑问题？
在更高的缩放级别下，出现不平滑的运动，主要是由于没有进行优化。具体来说，这是因为在较高缩放下，像素数量大幅增加，而每个像素的渲染速度不够快。目前的渲染并没有达到足够的优化水平，因此无法在每个像素上做到高效渲染。
如果将显示器宽度 (WidthOfMonitor) 和焦距 (FocalLength) 一起缩放，并保持相同的比例，效果会不会不同？
如果同时按相同比例缩放显示器的宽度和焦距，是否会改变投影效果，可以作为一个练习来思考。考虑到类似三角形的关系，显示器的宽度和焦距之间存在一定的比例。如果显示器的分辨率像素轴保持不变，那么在给定的显示器大小下，缩放显示器的宽度和焦距的同时，如何影响投影的比例。通过增加焦距并同时按比例增大显示器的大小，可能不会改变投影效果的线条。这个问题可以作为练习，去进一步思考并得出结论。
能否为用户提供一个滑动条，让他们在游戏开始时改变与相机的距离，就像一些游戏用伽马调整那样？
可以为用户提供一个滑块，在游戏开始时调整与相机的距离，就像一些游戏使用的伽马调整一样。实际上，已经做过类似的程序，其中包含了一个校准功能，允许用户设置与屏幕的距离。在这种情况下，会根据显示器的真实尺寸来进行一些计算，调整屏幕上文本的大小，使其适应最佳的阅读距离。这种方法有助于优化用户体验，确保屏幕元素根据观看距离进行适当的调整。