仓库: https://gitee.com/mrxiao_com/2d_game

回顾

我们当时在讨论我们必须要进行一些改进，以便在游戏中实现更好的碰撞检测。当时展示了一种非常基本的形式，以十字路口为例来实现碰撞交叉工作。然后我们意识到需要升级到更复杂的水平，以便能够处理更精确的碰撞。我们实现了一些碰撞区域，但效果并不理想。于是我们开始思考如何增强它，让它更加坚固，而不仅仅是让它无限薄。我曾经展示了这个问题的一个示例，演示了一些BUG，这样玩家可以偷偷地穿过这些碰撞区域。

碰撞问题

这个问题涉及到游戏开发中处理屏幕坐标和坐标环绕的挑战。玩家角色在屏幕上移动时，当超出屏幕底部时，其纵坐标会出现环绕，导致其坐标被“环绕”到屏幕顶部。这种坐标环绕的行为，在处理最大值和最小值时，产生了意外的结果，导致了一些不符合预期的行为，甚至出现了——即坐标值发生了不正常的变化。

在解决这个问题时，首先需要理解最大值和最小值计算中的特殊情况。由于屏幕上的坐标值超出预设范围后会出现环绕现象，原本预期的计算方式可能会导致错误的值，比如通过取最大值来处理坐标时，有时会出现不符合期望的情况。需要重新设计计算方式来避免这种“环绕问题”，其中一个可能的解决方案是通过减法来处理这些坐标，确保即使发生环绕，也能正确计算出最远的坐标。

这个问题的关键在于如何合理地处理坐标包裹和如何在不同的坐标值之间进行正确的比较。面对这种情况，开发者必须考虑更加稳定和有效的计算方法，避免因环绕导致的错误值。

思考问题

这个问题的核心是如何处理坐标在环绕和大数值计算中的变化。具体来说，问题出现在玩家角色的坐标当其越过屏幕边界时，如何确保坐标的正确计算。玩家从屏幕底部向上移动，若其坐标超出屏幕底部，就会回绕到屏幕顶部，这种“环绕”行为需要特别注意。

在处理这些坐标时，目标是找到一种方法来确保无论玩家从哪个位置开始，能始终准确地计算出最短的路径或最小值。我们希望能够从一个较大的值（如四十亿）开始，并计算到零，而不会因为坐标环绕导致错误的计算结果。

一种想法是，计算每次迭代时的差值，并根据差值来确定是否需要加一或减一，确保方向选择最短。比如，如果要计算从零到四十亿的距离，可以选择直接加一，确保方向正确。另一方面，如果从四十亿回到零，可能需要使用减法，并判断符号来决定正确的路径。

这个过程涉及到如何处理有符号数和无符号数的差异，如何利用最小值和最大值来确定计算路径。为了避免错误，最好能通过简单的差值计算来避免过多的检查或复杂的判断条件。

总结来说，最关键的是通过减法和加法来决定方向，确保在坐标环绕和计算过程中能得到正确的结果。

更改碰撞检测循环

这段内容涉及了编程中的一些具体步骤和调试过程，特别是关于坐标系统、符号位的计算、以及在程序中如何处理玩家位置等相关内容。以下是详细总结：

1. 坐标和符号位
   程序中涉及了对玩家位置的操作，主要是在 x 和 y 轴上计算偏移。通过逐步更新坐标，使用了增量值（delta x 和 delta y）来调整位置。这些增量值取决于坐标的符号，用以决定是向左、向右、向上还是向下移动。

2. 程序中的循环结构
   程序中使用了循环来处理从当前玩家位置到目标位置的每个步骤。每次迭代都会检查是否达到了目标位置，如果是，则结束循环。如果位置没有达到目标，则继续增量，直到满足条件。

3. 符号的计算
   对于坐标的增量，计算了符号（即方向）。原本期望能够使用标准的符号计算函数，但由于某些原因，决定手动实现符号的计算。通过检查坐标的高位来判断符号值，从而决定方向（正方向或负方向）。如果符号位为正，则方向为正，反之则为负。

4. 调试过程
   调试过程中设置了断点，检查玩家在不同步骤中的位置变化。通过断点检查，发现有时候程序并没有按照预期执行，特别是在初始位置计算时。需要在代码中调整玩家的初始偏移量以及位置计算方法，以确保程序按预期运行。

5. 逻辑优化
   程序中出现了需要优化的地方，尤其是坐标更新和符号计算的部分。通过调试和代码重构，逐步确保程序按预期正常执行，并处理好每个玩家的位移和位置更新。

6. 符号位操作
   对于符号的操作，考虑了在计算增量时，如何通过符号位（sign bit）来处理坐标方向。尝试使用不同的方式来计算符号，最初计划使用编程语言内建的符号计算功能，但遇到了一些问题，最终决定手动处理这些符号位。

signbit 是一个用于确定一个数值符号的函数，通常在编程中用来检查一个数值的符号位。它返回一个布尔值，用于判断一个数值是正数、负数还是零。

• 返回值:
  • 如果数值为负数，signbit 返回 true。
  • 如果数值为正数，signbit 返回 false。
  • 如果数值为零，signbit 的返回值通常也为 false。

C/C++ 中的 signbit 使用

在 C 或 C++ 中，signbit 是一个标准的数学函数，定义在 <math.h> 头文件中。它的使用方式如下：

#include <math.h>
#include <stdio.h>int main() {double num = -10.5;if (signbit(num)) {printf("The number is negative.\n");} else {printf("The number is positive or zero.\n");}return 0;
}

例子解释

• 如果 num 是负数，signbit(num) 返回 true，打印 “The number is negative.”
• 如果 num 是正数或零，signbit(num) 返回 false，打印 “The number is positive or zero.”

应用场景

• 符号判断：用来判断一个数值是否为负，通常用于物理计算、数学计算或数据处理。
• 位运算：在处理二进制数据时，signbit 可以快速判断符号位。

对比其他符号判断方法

signbit 只检查符号位，而其他方法（例如检查是否小于零）可能需要更多的计算。因此，signbit 更加高效，尤其在需要频繁检查符号位时。

使用注意

• signbit 适用于浮动点数（如 float、double 等），对于整数类型，通常使用比较运算符 > 或 < 来判断符号。

测试新的包围解决方案

我们需要处理玩家和环境之间的互动，以及玩家在移动过程中是否会受到边界限制。这个环绕方案涉及到如何处理玩家在瓦片地图中穿越边界时的逻辑。主要的挑战在于确保玩家的移动和相机视角能够顺畅过渡，而不让游戏体验受到突兀的中断。

例如，当玩家接近地图的边缘时，需要强制他们穿越到对面，以创建一个自然的流动感。同时，确保相机能够及时跟踪玩家的位置，使得玩家在地图上的移动是无缝的。这个方案也需要处理如何更新玩家的位置和视角，避免出现玩家消失或视角不准确的问题。

总体而言，处理复杂的移动和相机互动是确保游戏流畅性和沉浸感的重要因素。

修复相机位置

在设计环绕方案时，我们必须全面考虑玩家与相机的交互，以及如何处理边界的环绕逻辑。特别是在允许玩家穿越地图边界时，确保体验的平滑性尤为重要。然而，这也带来了许多复杂性和额外需要处理的内容。

环绕逻辑的挑战

我们需要在环绕点上考虑相机如何动态适应玩家位置。如果环绕逻辑没有妥善设计，很可能会出现以下问题：

• 玩家位置和相机位置的同步失效，导致玩家“消失”或视角偏移。
• 复杂的计算需求，比如要考虑相机视角的最近中心点，并在世界边界处进行环绕计算。
• 在数值上处理相机位置的环绕点时，需要特别小心，避免出现错误的结果。

简化的相机逻辑

为了使环绕机制更加直观，可以考虑以下简化逻辑：

1. 确定相机的参考点：将相机的位置设置为玩家最近的可视中心点。这个中心点可以通过对玩家的绝对瓦片位置进行分组计算得出。
2. 动态调整：根据玩家的位置动态调整相机，而不依赖复杂的边界环绕。这样可以确保相机始终能够跟随玩家的运动。
3. 分割逻辑：将绝对瓦片位置与相机视角绑定，并按一个固定的分组比例（如17瓦片为一组）进行计算。这种方法可以避免复杂的环绕点逻辑，并保证相机视角和玩家位置之间的平滑过渡。

边界环绕点的处理

边界环绕点是环绕逻辑的一个关键挑战。在这种情况下：

• 我们需要确保相机能够正确识别玩家的当前视角，而不会因为数值的超出范围导致错误。
• 环绕点附近的计算需要特别处理，例如当瓦片编号从较大的值回绕到较小值时，相机仍需准确识别玩家的正确位置。

通过这种方式，我们可以在不牺牲环绕逻辑正确性的前提下，显著简化相机和玩家之间的互动逻辑。最终目标是确保玩家体验的顺畅性，同时减少开发过程中的复杂性。

描述相机位置问题

在构建屏幕环绕和地图边界逻辑时，我们发现了一些复杂的问题，尤其是在地图尺寸和屏幕布局的整除性方面。以下是我们的思考和解决方案的总结：

环绕逻辑的局限性

1. 地图尺寸与屏幕布局的整除性
   我们希望屏幕布局为17x9的比例，但实际地图的尺寸（如40亿瓦片）并不能被17或9整除。这意味着，在地图边界的环绕点上，屏幕无法正确对齐，从而导致以下问题：

   • 屏幕可能会错位，显示不完整的内容。
   • 显示的部分可能同时包含世界的顶部和底部，破坏了正常的用户体验。

2. 屏幕环绕带来的额外复杂性
   为了解决边界环绕问题，必须引入更多的计算逻辑，如动态调整最近的屏幕中心点。然而，这增加了代码的复杂性，且可能引入潜在的错误。

解决方案的权衡

经过权衡，我们决定限制屏幕环绕的发生，以避免上述问题。具体而言：

• 不允许屏幕环绕
  为了简化逻辑，屏幕不再在地图边界处环绕到另一侧。这意味着世界地图采用“圆盘拓扑”，而非“环形拓扑”。屏幕始终以地图的中心区域为基准，避免因边界问题导致的不一致。

• 调整地图尺寸
  我们可以通过选择接近地图尺寸的17倍数作为边界，来减少因整除性问题导致的复杂性。例如，选择最接近40亿且可被17整除的值作为地图的最大尺寸，确保屏幕始终可以平滑地对齐。

• 取消环绕逻辑的支持
  由于屏幕环绕带来的问题比其解决的问题更多，因此我们决定完全取消环绕的支持。在屏幕逻辑中明确地禁止环绕，使得开发过程更加直观，并减少潜在的边界错误。

决策理由

1. 环绕逻辑的实现复杂且易引发错误，尤其是在边界环绕点处。
2. 取消环绕后，屏幕逻辑更加清晰，便于调试和维护。
3. 尽管屏幕环绕在理论上可以实现，但从实际效果来看，其价值并不足以支撑额外的开发工作量和复杂性。

通过这些调整，我们能够以一种更简单、更可靠的方式实现地图和屏幕的交互，同时确保用户体验的一致性。这种方法虽然限制了某些拓扑功能，但提升了整体系统的稳定性和可维护性。

从环绕变换到圆盘

在构建和调整屏幕动作及地图逻辑时，我们明确了几个关键点和改进方向，以确保系统的稳定性和功能性。

初始屏幕和地图逻辑

1. 屏幕从地图中心开始
   我们决定将屏幕的初始位置设置为地图的中间区域，并根据需求从那里开始展开。这有助于：

   • 避免屏幕环绕带来的问题。
   • 提供一个清晰的起点，便于逻辑的定义和调试。

2. 瓦片地图的调整
   我们需要重新定义瓦片地图的分块索引，以支持当前的屏幕起始设置。这是因为之前的实现基于固定的硬编码数组，导致了在某些场景下的限制。

3. 稀疏存储的未来实现
   当前的逻辑尚未实现完整的稀疏存储。未来在支持稀疏存储时，可以允许任意值的动态分配，这将进一步增强系统的灵活性和适应性，但这不是当前的重点。

玩家与相机的初始化

1. 玩家与相机的起始位置关联
   我们计划将玩家的初始位置设置在相机视野范围内。具体来说：

   • 确保相机起始时能够看到玩家所在的区域。
   • 通过相机的初始位置定义玩家的生成区域，或反过来根据玩家位置调整相机。

2. 简化逻辑以避免问题
   为了减少不必要的复杂性，决定先将墙体障碍物恢复到原始状态。这可以确保玩家和相机的起始位置在系统中合理分配，同时避免了边界问题。

碰撞检测的优化

1. 减少次要问题的干扰
   在调整屏幕和地图逻辑时，我们避免追逐次要的bug，这些问题主要源于系统逻辑尚未完全定义。通过专注于关键功能的实现，可以更高效地解决主要问题。

2. 精确检测的实现
   当前，碰撞检测的逻辑正在完善中。通过合理定义墙体和玩家的关系，以及明确边界的交互方式，可以实现更精确的碰撞处理。

总结

• 屏幕逻辑的调整使其更稳定，从中间开始的设计提供了清晰的基础。
• 玩家与相机的初始化进一步增强了系统的直观性。
• 未来稀疏存储的实现将带来更大的灵活性，但当前的重点是完善现有逻辑。
• 在碰撞检测方面，通过专注于核心问题，逐步优化逻辑，确保系统在功能性和性能上的平衡。

通过以上优化和设计调整，我们能够更加系统地推进功能开发，同时减少复杂性和潜在的错误风险。

通过区域而不是点来改进碰撞检测

---

碰撞检测优化的方向

1. 碰撞检测的精确性
   当前的碰撞检测系统已经取得了一些改进，例如：

   • 穿墙的可能性显著降低，但理论上依然可能发生。
   • 优化后，墙体的碰撞反应更加稳定，但需要进一步验证具体原因。

2. 从点到区域的处理
   计划将碰撞检测从“点”的逻辑转变为“区域”的逻辑，这样可以：

   • 更好地模拟真实的碰撞场景。
   • 解决角色可能卡在墙体中的问题。

3. 滑行机制的引入
   为碰撞检测加入滑行逻辑，以实现更自然的移动体验。这是对系统交互逻辑的一种扩展，也是改进用户体验的重要一步。

---

现阶段遇到的问题

1. 调试为主的开发阶段
   今天的工作以清理和调试为主，而非新增功能的开发。主要处理了几个奇怪的bug，包括：

   • 部分颜色和显示效果异常。
   • 某些功能无法按预期触发。

2. 系统逻辑的限制
   当前存在一些功能性限制，例如：

   • 部分墙体仍会因逻辑缺陷产生穿透问题。
   • 某些代码逻辑对于变量的约束不够明确，导致了实现上的困难。

---

下一步的计划

1. 重新定义角色和相机的交互
   明天将着手编写新的碰撞检测逻辑，包括：

   • 修复角色粘墙的问题。
   • 使角色能够动态适应不同的碰撞区域。

2. 复盘系统中的问题
   准备整理当前代码中的to-do事项，优先修复高优先级的bug，以保证系统的稳定性。

3. 简化逻辑的实现
   当前的逻辑过于复杂，需要进一步优化代码结构，特别是在碰撞检测和滑行功能的实现上，争取实现简单而高效的解决方案。

---

总结来看，今天是一个以调试和清理为主的工作日。虽然没有引入太多新功能，但解决了若干影响整体功能稳定性的bug，为明天的开发奠定了基础。下一步将专注于碰撞检测逻辑的优化，并继续解决系统中其他遗留问题。

修复规范化

今天的主要工作是尝试解决之前导致问题的核心原因，并为未来避免此类问题奠定基础。

首先，我们打算优化偏移参数的使用方式。之前的偏移量经常被修改，容易引发问题。为了解决这个问题，我们决定通过引入一个专用函数来处理偏移的变更操作。这样可以避免手动修改时可能出现的错误，同时也使代码更加清晰和规范化。

新的函数将负责处理偏移计算。这个函数会接收一个初始值以及一个偏移量，然后返回计算后的新值。这样一来，当我们需要对某个值进行偏移时，可以直接调用这个函数，而不需要再手动处理具体的偏移逻辑。这种做法不仅减少了出错的可能性，也提升了代码的可维护性。

接下来，我们还对一些相关代码进行了重构。例如，我们将偏移的计算逻辑应用到之前手动实现的部分，将其替换为新的函数调用。此外，我们还标记了某些不应频繁修改的变量，以提示后续开发中需要注意的地方。

在这一过程中，我们还检查了代码中可能的其他问题。例如，我们清理了一些已经不再使用的变量和逻辑，确保代码更加简洁高效。同时，也审视了一些渲染相关的代码，因为这些部分直接访问了数据值，我们确认这些访问是合理且必要的。

尽管今天的工作主要集中在调试和优化现有代码，但我们也意识到还有许多需要改进的地方。例如，未来可能需要进一步统一逻辑处理方式，确保所有相关模块都遵循一致的规则。我们的目标是逐步完善系统，减少潜在问题，提升整体的稳定性和效率。

虽然今天的开发过程并不顺利，遇到了许多挫折，但这些问题为我们提供了改进的机会。我们会继续完善代码，使其更加稳健，同时总结经验，避免类似问题在未来再次出现。

接下来的几周内，我们计划进一步完善系统设计，明确未来的开发方向，并尝试构建一个更稳定、高效的开发流程，以支持更复杂的需求。

讨论地图的未来

我们目前没有出现那些复杂的坐标处理问题。
不过，因为我们最终希望达到的效果，我暂时还不确定具体如何实现这个目标。
理想的状态是：

• 当对象位于屏幕范围内时，它们的坐标在一个规则的浮点空间中；
• 当对象超出屏幕时，它们进入某种"标题地图位置"或"离屏存储"的状态；
• 一旦对象返回屏幕，它们会被映射回浮点坐标，通常相对于屏幕中心或类似的基准点。

最终，我们的目标是完全避免直接依赖瓦片地图坐标。理想状态下，我们希望所有对象都在浮点空间中进行游戏逻辑的处理，当对象离开屏幕时，可以将它们切换到某种“冷存储”状态中，而不需要持续计算。

目前还不完全清楚如何实现这个目标，但随着我们推进更多的工作，我认为这是可以实现的。

同时，通过修复一个错误，我们意外优化了碰撞部分的逻辑，尽管这并不是我们的初衷。此外，我们认为避免环绕式地图的实现可能是更好的策略。虽然环绕式地图理论上可以实现，但它可能会引发许多不必要的问题，因此我们更倾向于避免采用这种方式。

对于环绕逻辑，我们的初步决定是：

• 避免允许对象环绕地图。
• 从功能角度来看，环绕机制将被视为不存在。

尽管如此，这一决定目前还不能完全确定，我们需要进一步观察。

今天的工作主要集中在基础的代码清理和调试上，虽然这些工作并不复杂，但它们对后续的开发是必要的。我们明天计划进一步完善碰撞区域的逻辑，目标是：

• 使玩家或对象可以是任意形状；
• 使墙壁也可以具有复杂形状；
• 实现形状之间的精确交互和碰撞检测。

此外，我们可能会探索默认颜色配置的问题，虽然目前的工具似乎不支持直接设置默认值，但我们会尝试找到解决方案。如果没有现成的方法，可能需要考虑其他替代方案。

总的来说，这一天的工作虽然没有太多亮点，但完成了重要的调试和清理任务，为后续开发铺平了道路。

你在实际工作中经常使用图表吗？

我们在调试过程中发现了一些问题，主要是因为之前的处理过于草率。通过这次调整，我们已经明确了接下来的一些优化方向，避免类似问题的再次发生。

主要的改进方向包括：

• 避免直接使用偏移量，只有确实需要访问偏移的逻辑才会真正访问它。
• 尽量减少瓦片索引与偏移量之间的频繁交互。

这次的调试暴露了一个问题：虽然看似封装的逻辑可以简化操作，但实际上可能会引入更多不必要的复杂性。因此，我们希望能进一步优化，使游戏逻辑统一在一个空间中进行，减少中间层次的频繁转换。

长期目标是：

• 通过将所有对象映射到同一个浮点空间中，简化计算和逻辑处理；
• 只在必要的时候进行最终的绘制转换。

这样可以避免逻辑中断裂和不必要的操作，从而提高代码的清晰性和可靠性。

对于图表和视觉化的帮助：
在解决特别复杂的问题时，绘制图表是一种非常有效的方法，即使只是为了自己理解。在分析和解决问题时，通过笔记本中的草图或图表来理清思路是一个很好的习惯，特别是在处理需要准确理解逻辑关系的场景时。

通过这次调试，我们不仅修复了问题，还明确了未来工作的重点。这些经验将帮助我们更高效地应对接下来的开发任务。

推荐学习C++的书籍？

关于学习C++的建议，我们无法给出当前最优的资源推荐。因为学习C++的时间已经过去很久，不熟悉现在的学习资源和方法。

过去学习C++时，使用的资料可能已经过时，目前可能存在更高效、更适合初学者的学习资源。不过，由于缺乏对最新资源的了解，无法明确指出具体的推荐。

建议可以通过以下方式寻找适合的学习资源：

1. 在线课程平台：如Coursera、Udemy、edX等，这些平台上经常会有高质量的C++课程，内容系统且贴近实际应用。
2. 官方文档和参考书：C++官方文档和权威书籍，如《C++ Primer》和《Effective Modern C++》，适合深入学习。
3. 社区和论坛：通过像Stack Overflow或Reddit等技术社区，与有经验的开发者交流，获取学习建议和资源推荐。
4. 实践为主：C++的学习需要结合实践，可以从简单的项目或开源代码入手，逐步提高对语言特性的理解。

学习C++是一项长期投入的过程，选择资源时可以根据自身的学习习惯和需求，找到最合适的方式开始探索。

对DX12的初步看法？

对DirectX 12的最初看法是，随着向缓冲区访问类型的直接推送趋势，感觉是积极的。这种转向理论上带来了更好的性能和效率。然而，关键在于实际的最终运输产品。如果实际实现不如预期，好的想法可能会变得糟糕。因此，我需要看到这些技术的实际效果和最终表现，才能确定它们的好坏。

为什么不使用带符号值作为顶坐标？

使用带符号的值来表示pta坐标，从世界的零点开始，并进行负向的动作，这样的设想在理论上是可行的。这种方法可以使我们在地图查找过程中更灵活地处理位置。然而，这一方法的实际实现可能会受到许多因素的影响，例如在世界中引入的不完全性和地图查找的效率。我们可以利用正弦值来表示这些规划中的移动，从而更好地映射和处理在不同坐标系中的位移。

为什么你不喜欢“private”？

不喜欢使用“private”关键字，因为在某些情况下，代码需要访问这些私有字段，这会导致一些问题。这样做意味着必须让别人了解这些信息，或者使得代码更复杂，因此觉得“private”阻碍了开发的流畅性。个人更喜欢在需要时给自己做笔记，表示这些代码或字段仅限于特定场合使用，而不需要对外部暴露。当“private”阻碍正常开发时，通常选择避免使用。

你认为广播声音从浮动空间到下一个房间会有任何复杂性吗？

讨论了一个浮动空间的设定，其中涉及的世界和房间是基于某种立方体结构（例如3x3x3的房间）。在这种设定中，玩家的位置是相对于空间的中心浮动的，而不是固定的。当玩家从一个房间移动到另一个房间时，相机会根据玩家的位置进行调整，所有人的位置也会更新。玩家不再是固定在某个区域，而是随着空间的浮动，能够跨越不同的区域。与此相关的元素包括将空间划分成“瓷砖位置”，这些位置在休眠状态下，只有特定区域会在任意时刻浮动和运行。整个世界虽然活跃，但这种浮动和空间更新的方式仍然是高层次的抽象设计。

我对内存对齐有什么了解？

讨论了内存对齐的问题，特别是在进行内存分配时，需要采取措施确保数据的正确对齐。为此，必须确保所有的数据都以正确的方式存储，以避免内存偏差的发生。

为什么你要做得比应该的复杂一些？

讨论了为什么在处理世界的大小时需要避免使用双精度浮点数（double）。双精度数会降低性能，因为它们比单精度浮点数（float）慢，且有时性能不如预期，因此不适合大世界的处理。为了确保世界足够大，同时保持性能，决定在局部使用浮动数（float）。这样可以保证处理过程中世界的每个部分都在浮点数范围内。然而，这些浮点数的数据最终会存储到瓦片地图中，而不是直接以浮点数的形式存储。

系统在后台渲染屏幕外物体吗？

系统计划在后台模拟而非渲染离屏对象。这意味着，虽然不直接渲染这些对象，但会在后台进行必要的处理。

结构体初始化看起来很奇怪

在C++11中，为了进行初始化，某些操作必须遵循特定的规则。特别是，如果不想给某个变量起名字，必须使用内联声明的方式。这是C++11所规定的做法，尽管可能没有明确的解释或理由。

为什么会有环绕问题？

环绕问题的核心在于，当使用坐标环绕时，最小最大值的计算不再适用。允许坐标环绕可能导致两个看似接近的位置实际上相距极远，例如，四十亿单位。这就要求代码更加小心，以确保在处理位置时避免不直观的错误。而且，即使世界非常大，玩家也不可能走到边缘，因此不认为允许环绕是一个好的权衡。

C和C++在处理指针时有何不同？

关于指针处理，在不同的语言中，基本的指针操作是相同的。虽然在某些方面，如类和多重继承等，指针的处理方式可能有所不同，并且可能影响性能，但基本的指针概念和操作是一致的。

为什么不将瓦片宽度和高度改为8x16，以使相机能够使用2的幂进行包围？

使用版本控制是很重要的，虽然并不像一些人那样频繁使用分支和进行复杂操作，但基本的版本控制仍然被使用，主要用于文件备份。

关于游戏世界的“环形”设计，尽管这种设计可能会为玩家提供“穿越”地图的体验，但从游戏设计的角度来看，环形地图并没有实际的好处。选择让地图呈现环形世界并不会为游戏带来额外的价值，因此不需要特别实现。相比之下，简单地通过控制地图的大小并不限制游戏体验，反而更符合游戏需求。

总之，游戏的设计可以根据具体需求灵活调整，而不必拘泥于某些技术实现。如果环形地图无法为游戏带来实际优势，选择不实现环形地图可能是更好的决策。

你可以解释一下在碰撞中如何使用Minkowski加法吗？

在多边形和圆形碰撞系统中，首先会处理简单的情况，比如圆周运动和基本的矩形碰撞。这些基本的碰撞检测是容易实现的，甚至可以通过旋转矩形或使用更大的矩形来简化碰撞判断。

当开始处理更复杂的碰撞检测时，系统会变得更加困难，尤其是当涉及到旋转碰撞体积时。在游戏中，旋转的碰撞体积可能并不常见，但将来可能会有一些系统会使用这些功能来支持更复杂的碰撞。

尽管如此，当前实现的优先级是处理简单的形状（如圆形、矩形和椭圆），这些形状的碰撞检测相对容易。随着开发的推进，更复杂的功能将会被逐步实现。最终，碰撞系统将会包含更多的几何形状和更复杂的计算，直到完成更全面的碰撞检测。

你会在未来添加瓦片实体吗？

在完成动画控制之后，开发将集中在让角色在屏幕上移动和相互作用的部分。此时，碰撞检测是开发过程中的最后一个需要解决的难题。一旦完成了这些基础工作，接下来将会阐明如何处理世界的构建，特别是瓷砖上的元素。

在最初的开发阶段，虽然地图已存在，但并没有立刻加入瓷砖实体。之所以没有这么做，是因为当时向量系统还没有完成，因此无法有效处理这些地图元素。当开始使用向量进行世界构建时，情况会变得更加复杂，因为将涉及到更多的元素和细节。

总体而言，当前的优先级是完成动画控制和碰撞检测等基本功能，然后再逐步处理更复杂的世界构建和瓷砖实体相关的内容。

对瓦片实体的关注有多大？

关于瓷砖实体的关注，目前并不确定会投入多少精力在这一方面。虽然瓷砖地图被认为是生成世界的最简单方式，但最终的游戏可能并不会完全依赖瓷砖地图。在实际开发过程中，可能会放弃这一方式，转而探索其他方法。

目前的主要挑战是如何创造一个世界地图，并确保最终的结果符合预期。由于这是第一次进行这样的开发工作，虽然已有一些经验，但很多方面仍然不确定。在处理这些问题时，开发者也会像玩家一样进行尝试和调整，以便了解哪些功能有用，哪些可能需要修改或放弃。

如果将一个9x9的瓦片网格转换为玩家作为原点再做世界地图怎么办？

目前还不确定最终会采取什么样的方式，因为基本的系统还在开发中。虽然有一些初步的想法，但在最终确定之前，还需要完成更多的基础工作。直到这些工作完成之前，无法明确预测未来的具体实现或方向。