游戏引擎学习第30天

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

回顾

在这段讨论中，重点是对开发过程中出现的游戏代码进行梳理和进一步优化的过程。

工作回顾：在第30天，回顾了前一天的工作，并提到今天的任务是继续从第29天的代码开始，特别是继续处理瓦片地图。表示，如果将第29天的代码解压到一个目录并开始使用，就会处于当前的开发状态。
瓦片地图与玩家移动：当前开发的核心目标是让玩家能够在不同的瓦片地图之间移动。通过简单的矩形表示来避免复杂的位图操作，确保游戏中的移动和更新逻辑能够顺畅地进行。
代码结构和逻辑：分享了游戏中的代码结构，提到通过数组来表示瓦片地图，其中包含了地图的不同类型。代码通过将地图的不同元素（如位置、指针等）存储在结构体中，进而支持在多个地图之间切换。也提到，在早期的开发过程中，尽管已经做了很多规划和结构设计，但实际上并没有完全实现这些设计，只是处理了大部分的地图抓取和玩家位置计算。
变量和内存管理：通过一些常量变量和指针的引用来管理代码逻辑和内存分配，尽管当前的代码存在一些冗余和不完善的部分，但强调了代码逐步优化和清理的过程。
逐步推进：提到，尽管在开发过程中有很多问题需要解决，但会通过逐步推进来改进代码。提到的“中溪”可能是指代码逐渐清理并理顺的过程，通过小步骤逐步解决问题。
代码重构和简化：没有立即解决所有问题，而是通过逐步编写和重构来简化代码，并慢慢将代码引导到正确的方向。表示，很多时候，代码优化和结构调整的答案已经很明确，但需要通过实际的编程和调试逐步实现。

总结来说，这段讨论展示了一个开发过程中不断调整和优化代码结构的过程，尤其是在处理地图逻辑、玩家移动、和变量管理方面，尽管在开发过程中遇到了一些问题，但通过逐步的调整和清理，代码将逐渐朝着更高效和更清晰的方向发展。

编写代码的过程；先写乱的，后清理

在这段讨论中，核心观点是关于编写代码时的最佳实践，特别是如何在初期阶段处理代码的混乱性。

混乱的代码与迭代开发：强调了在编写代码时，尤其是在初期阶段，不应该过早追求完美和干净的代码。相反，应该先快速写出一个“糟糕的代码”，这段代码可能不完美，但它可以尽早实现功能，并展示出开发的基本操作。重点是快速验证想法和实现目标，而不是一开始就纠结于代码的整洁性。
探索与清理的过程：在初期开发过程中，开发者建议不要过度思考代码的清晰度，因为这样做可能会浪费大量时间。初期的代码主要是为了探索和实现功能，只有当基本功能已经实现并且工作正常时，才开始清理和优化代码。
写干净代码的时机：当代码是“过渡性的”，即只是为了完成特定任务并不打算长期保留时，花时间使其整洁是没有意义的。过早追求干净代码可能会导致在不需要的地方浪费时间。只有在代码将会长期存在时，才值得投入时间进行优化和清理。
避免不必要的时间浪费：开发者通过类比来强调，花时间清理短期的、过渡性的代码就像是在浪费金钱。如果认为时间就是金钱的话，那么过度优化早期的代码相当于拿着金钱烧掉，这在开发过程中是不可取的。

总结来说，这段讨论主张在初期开发过程中应专注于实现功能而非追求代码整洁，只有在验证和探索完毕之后，再去清理和优化代码。过早的代码清理可能会浪费宝贵的时间和精力，特别是当这些代码并不打算长期存在时。

传递关于地图瓦片的信息

在这段讨论中，主要内容集中在如何在一个平铺地图的基础上进行玩家位置的处理，并开始考虑如何让玩家移动。

玩家位置和瓷砖地图：首先，讨论了玩家在平铺地图中的位置概念。玩家的位置被表示为在某个特定的Tile地图中，具体的位置由玩家的 x 和 y 坐标给出。目标是通过函数获取玩家在该地图中的位置。
函数和查询：提到了一个函数，用于从一个平铺地图的 XML 文件中获取地图，并且能够通过坐标查询特定的Tile地图。这个函数还会进行边界检查，确保在正确的地图范围内操作。
坐标顺序：在讨论坐标顺序时，指出在编码过程中通常会先处理 x 坐标，然后是 y 坐标，尽管在某些情况下可能会相反。为了解决这一点，选择了适当的顺序，以确保在查询和访问地图数据时的逻辑正确。
边界检查：在实现查询功能时，还提到了进行边界检查的必要性，以确保玩家的坐标不会越界，玩家不会进入没有关联Tile的区域。
玩家移动：一旦这些基础功能完成，讨论转向了玩家的移动。当玩家需要从当前屏幕或Tile地图离开时，需要处理如何移动到下一个地图，并确保这一过程能够正确更新玩家的位置。
游戏状态初始化：指出游戏状态需要在初始化后进行设置，因为在初始化之前，游戏的状态信息还没有准备好。这涉及到如何在程序启动时加载和管理游戏的状态。

总结来说，这段讨论的重点是如何处理玩家在不同的Tile地图中的位置，确保通过函数和查询来获取玩家的坐标，并在移动时进行适当的边界检查。此外，还需要处理游戏状态的初始化和更新，以便确保游戏中的玩家能够正确移动并进入不同的地图。

在这里插入图片描述

检查玩家是否正在移动到不同的瓦片地图

在当前的实现中，玩家的移动被限制在一张瓷砖地图内。当玩家试图穿越地图边界时，程序会检查玩家的位置，并根据当前地图的边界来判断玩家是否应该被阻止。系统会将玩家的位置视为地图中的“极端位置”，即接近或超出地图边缘的区域。

在这一点上，原本的假设是当玩家到达边界时，如果他们越过地图的边缘，他们将进入一个“无人区”，即没有有效数据的区域。程序会认为如果玩家越过了地图的某个边界（例如左、右、上、下），则该区域会被“填充”或“填补”以防止玩家超出范围。然而，现在需要改变这一假设，开始考虑到这些“空白”区域可能并不是填充的，而是另一张新的地图的一部分。也就是说，当玩家离开当前地图时，可能会进入另一个有效的地图。

为了解决这个问题，需要修改程序逻辑，允许它在多个瓷砖地图之间进行跳转和切换，而不是仅限于一个地图。通过访问多个瓷砖地图，玩家的移动不仅仅限于当前地图的边界，而是可以跨越多个地图区域。

程序的设计应开始考虑以下几个方面：

多个瓷砖地图的访问： 需要更新逻辑，以便能够跨越多个地图。
地图切换机制： 如果玩家试图离开当前地图的边界，应根据新位置来加载新的地图。
地图坐标转换： 可能需要定义一种机制来管理世界坐标和瓷砖地图坐标之间的转换，以便正确地定位玩家的位置。

这意味着程序应该能够处理玩家在不同地图之间移动时的“边界检查”，并且能够处理玩家从一个地图进入另一个地图的情况。因此，当前的假设需要更新，以便能够在多个地图间平滑过渡。

这涉及到：

坐标系统更新：通过新的坐标系统来处理玩家的实际位置。
地图加载和切换：通过在不同的瓷砖地图之间进行查找，加载相应的地图数据。
边界检查机制的扩展：不仅仅检查当前地图的边界，还要能够判断是否需要加载新地图。

通过这种方式，玩家的移动将不再受限于单一的瓷砖地图，而是可以流畅地在多个地图之间过渡。

找到下一个瓦片地图并查询位置

你提供的文本内容描述了一个在程序中使用平铺地图（tile map）以及如何处理越界情况的技术细节。以下是对主要概念的总结和解释：

平铺地图与越界处理：
- 在开发中，通常我们使用二维数组来表示平铺地图。在程序中，当玩家走出地图边界时，需要进行越界处理。例如，如果玩家的x坐标小于0，或者x大于地图的宽度，就需要将玩家的位置映射到下一个地图。
- 这种处理方式允许玩家在多个地图间移动，避免了硬性的边界限制。
坐标映射：
- 如果玩家的坐标（例如x）小于0，程序会把该坐标映射到当前地图的另一边，或者到下一个地图。这种映射不仅限于x轴，也适用于y轴。
- 这种方式确保了玩家在跨越地图边界时，位置能够自然过渡到新地图，而不是简单地阻塞玩家的移动。
地图大小和偏移量：
- 由于每个地图的尺寸可能不同，程序会根据地图的宽度和高度来调整坐标。例如，如果玩家从左边界走出，x坐标可能会变成负数，程序会根据当前地图的宽度来调整玩家位置到新地图。
统一的世界视角：
- 程序并不会允许每个城市的地图大小不同。为了简化处理，程序将所有地图设置为统一大小，或者通过缩放来适应视图。这避免了处理不同尺寸地图时的复杂性。
- 这意味着，无论地图的实际尺寸如何，玩家始终会在屏幕上看到一个固定数量的平铺块。
通过世界指针访问数据：
- 所有地图数据不再仅仅是单独的城市地图的属性，而是被抽象为世界的一部分。这意味着，玩家在不同地图之间移动时，程序会根据当前世界的数据来计算新的位置，而不是仅仅依赖于单一地图的坐标系统。
函数和异常处理：
- 在代码中，使用了多个函数来处理地图数据，并且通过异常处理来确保当玩家越界时，程序能够正确处理并返回有效的地图数据。比如，通过检查坐标是否超出边界并调整到下一个有效位置。

7 坐标计算与分数值

在游戏中，玩家的坐标和地图的网格单元（tiles）是分开的。坐标计算时，可能会得到分数值，尤其当玩家的宽度是一个奇数时，除以2会产生分数。
这种分数值在进行坐标计算时可能引起问题，导致不准确的结果。通过调试，可以发现分数值的产生源于玩家宽度的奇数性，进而影响坐标系统。

越界检查与地图更新
- 游戏中使用的是一个多地图系统，当玩家从一个地图的边界离开时，需要判断是否进入新的地图。
- 越界检测是通过检查玩家是否越过当前地图的边界进行的。如果越界，则需要获取相应的新地图，并确保玩家的位置被更新到新的地图。
- 玩家在移动时，会经过一系列的检查，比如是否到达了地图的边界，是否触发了预定的“超出边界”条件，并返回正确的结果。
地图瓦片和空值处理
- 游戏中的每个地图都由多个“瓦片”组成，每个瓦片都有特定的属性。程序会根据玩家当前位置计算其所在的瓦片。
- 在处理瓦片时，程序会检查瓦片是否为空（即没有有效数据）。如果是空的，那么玩家就不能停留在该位置，程序会返回一个空值并进行相应的处理。
- 空值处理是关键，因为如果没有正确地处理空值，玩家就可能在地图上移动到无效区域，从而造成错误。
返回值和错误修正

通过调试，发现了一个错误：在某些情况下，程序没有正确返回瓦片的状态，导致玩家的移动无法正确处理。这个错误的根源是返回值未被正确使用，因此需要修正这一点。
在修复错误后，玩家能够正确地在地图上移动并跨越不同的地图边界。

清理与优化

在成功解决了主要的功能问题后，接下来的任务是清理代码。这包括将多次使用的代码封装成函数，提高代码的可重用性，并减少冗余。
清理代码不仅有助于提高程序的可读性，还能减少潜在的错误，提高程序的稳定性和性能。

在这里插入图片描述

计算在新瓦片地图中的位置

上面的内容描述了一个关于处理世界坐标和瓦片地图坐标的过程。主要讨论了如何将原始位置（即玩家或物体的某个坐标）转换为规范位置，并进行相关的数学运算以确保这些位置在地图上的正确性。

主要想法：

位置自由漫游：所有坐标系统都是建立在“自由漫游”概念上的，即用户或物体可以在地图中任意移动，位置可以是动态的。
规范化位置：目标是将一个给定的原始位置（可能是一个无效的位置）转换为一个规范位置（canonical position）。规范位置是经过计算和调整的有效坐标，这样可以确保该位置符合系统的需求。
函数设计：设计了一个函数用于将原始位置转换为规范位置。该函数接受世界坐标，并返回一个规范的位置，其中包括：
- 计算并调整玩家或物体在瓦片地图上的位置。
- 如果坐标超出了当前瓦片地图的范围，需要对瓦片地图进行“重新对齐”。
- 使用内联函数来进行这些数学运算。
位移与规范化：根据当前的偏移量和瓦片地图的维度，函数会将超出范围的坐标调整到地图的另一边，以实现环绕效果。
数据结构：需要一个数据结构来存储相关的坐标信息，并返回给调用者。这个结构通常包括：
- 原始的世界坐标。
- 规范化后的坐标。
计算与返回：函数将计算并返回规范位置。该位置可以直接用于后续的操作，比如检查瓦片地图上的位置是否为空，或者进行其他与地图交互的计算。

理论扩展：

原始位置与规范位置：可以将“原始位置”看作是未经处理的坐标，而“规范位置”则是经过计算、调整并且适用于进一步操作的坐标。这样可以确保后续的计算不会因为不规范的坐标而导致错误。
处理瓦片地图层级：在进一步操作中，可能会考虑将这些计算进一步细化到瓦片的每一层级上，尽管目前的需求并不强烈。
位置抽象：通过这一过程，可以实现一个统一的坐标系统，使得从“原始位置”到“规范位置”的转换变得简单而清晰。规范位置可以帮助系统理解和使用坐标数据，而原始位置则提供了与外部世界的连接。

具体操作：

位置转换：通过对原始坐标的调整，确保它们在地图中始终处于有效范围内。
数据返回：将处理后的规范位置返回给调用者，并为后续的计算提供必要的信息。这样做的目的是为了确保系统在操作这些坐标时可以获得一致且有效的结果。
进一步的优化：可以考虑在更低层次上（例如瓦片级别）进行更多的优化，以便处理更复杂的地图需求或提高性能。

总结：

这个过程的核心目标是通过规范化原始位置，将它们转换为适合地图操作的格式。这种方法确保了即使在复杂的地图系统中，坐标计算和调整依然保持高效且准确。
在这里插入图片描述

在这里插入图片描述

解释一下上面代码
在这里插入图片描述

在这里插入图片描述

这行代码：

Result.X = X - Result.TileX * World->TileWidth;

用于计算当前瓦片内的位置，也就是相对于瓦片左上角的偏移量。下面是详细的解释：

全局坐标 (X, Y):
Pos.X 和 Pos.Y 表示的是世界坐标系中的一个点的位置。而你需要的是这个点在具体瓦片中的位置，也就是在瓦片内的局部坐标。
瓦片坐标 (TileX, TileY):
前面的代码通过将 X 和 Y 分别除以瓦片的宽度和高度来计算出该点所在的瓦片的列和行（即 TileX 和 TileY）。然后使用 TruncateReal32ToUInt32 来截断这些浮动值，从而得到一个整数瓦片坐标。
局部坐标:
这行代码 Result.X = X - Result.TileX * World->TileWidth; 计算的是该点在当前瓦片内部的局部位置。具体来说，它是通过从全局的 X 坐标中减去该瓦片左边缘的世界坐标来得到的。
- Result.TileX * World->TileWidth 给出了瓦片的左边缘在世界坐标系中的位置。
- 然后，X - Result.TileX * World->TileWidth 就是该点相对于瓦片左上角的偏移量。

这个计算的目的是获取点在瓦片内的相对位置，而不是全局地图的坐标。

Y 坐标也会使用类似的方式计算：

Result.Y = Y - Result.TileY * World->TileHeight;

这行代码同样是计算该点在瓦片内的垂直偏移量，即点相对于当前瓦片左上角的 Y 坐标。

总结来说，Result.X = X - Result.TileX * World->TileWidth; 这一行的作用是获取点在指定瓦片中的局部坐标，而不是全局坐标。

在你提供的结构体中，TileX、TileY、X 和 Y 有着不同的意义和用途，分别对应了瓦片地图的全局坐标、瓦片内的局部坐标等。我们来逐一解释它们的含义和区别。

1. `TileMapX` 和 `TileMapY`（全局瓦片坐标）

含义：表示整个地图中瓦片网格的坐标，也就是说，这是瓦片地图（TileMap）在整个世界中的位置。
- TileMapX 是瓦片地图在 X 轴上的位置。
- TileMapY 是瓦片地图在 Y 轴上的位置。
例如：假设地图由 10x10 个瓦片组成，每个瓦片大小为 100x100 像素。第一个瓦片的 TileMapX 和 TileMapY 都是 (0, 0)，第二个瓦片在 X 方向上的坐标是 (1, 0)，依此类推。

2. `TileX` 和 `TileY`（当前瓦片内的坐标）

含义：这是 相对于当前瓦片 的坐标，表示你所在瓦片内部的某个位置。
- TileX 是当前瓦片内的列坐标，表示该瓦片的水平位置。
- TileY 是当前瓦片内的行坐标，表示该瓦片的垂直位置。
例如：如果一个瓦片的大小是 100x100 像素，TileX 和 TileY 就是当前瓦片中的位置，范围是从 0 到瓦片的宽度或高度减去 1。例如，如果当前位置在瓦片的中间，TileX 和 TileY 可能是 (50, 50)，表示在该瓦片的中心。

3. `X` 和 `Y`（瓦片内的局部坐标）

含义：表示相对于当前瓦片的坐标，范围是 [0, TileWidth) 和 [0, TileHeight)，也就是说它们是当前瓦片内的相对位置，而不是全局坐标。
- X 是瓦片内部的水平坐标，表示点相对于瓦片左上角的水平位置。
- Y 是瓦片内部的垂直坐标，表示点相对于瓦片左上角的垂直位置。
例如：假设每个瓦片的大小是 100x100 像素，而 X = 50 和 Y = 50，这意味着点位于瓦片的中心。

总结它们的关系和区别：

TileMapX 和 TileMapY：表示瓦片地图在全局地图中的位置。这是全局坐标，每个瓦片都有一个唯一的坐标。
TileX 和 TileY：表示某个瓦片内的局部坐标，也就是该点在瓦片中的列和行位置。每个瓦片都有一个局部坐标系，从 (0, 0) 开始，到 (TileWidth-1, TileHeight-1) 结束。
X 和 Y：表示相对于当前瓦片内的具体位置。它们的范围是 0 <= X < TileWidth 和 0 <= Y < TileHeight，表示你在当前瓦片内的偏移量。

举例：

假设地图的瓦片尺寸为 100x100，整个地图由 4x4 的瓦片组成。

如果我们有一个原始位置 raw_position，假设 TileMapX = 1，TileMapY = 2，X = 150 和 Y = 230，这表示该位置在地图上的第 1 列、第 2 行的瓦片内，且该位置相对于瓦片左上角有偏移。

在 GetCanonicalLocation 函数中，程序会计算出当前瓦片内的具体位置（TileX 和 TileY），然后将这些位置转换为相对于该瓦片的局部坐标（X 和 Y）。

TileX = 1，TileY = 2 是该位置所在瓦片在地图中的位置。
X = 50，Y = 30 是该位置在该瓦片内的相对位置。

通过这种方式，你可以将一个全局位置（raw_position）转换为瓦片内的局部坐标（canonical_position）。

在这里插入图片描述

存储相对于瓦片的X和Y位置

在一个关于瓷砖地图（Tile Map）和位置转换的项目，正在探索如何处理瓷砖地图上的坐标，确保在移动和调整过程中处理位置和坐标的正确性。这个过程涉及到如何将坐标从原始位置映射到相对于瓷砖的规范位置，避免误差和不必要的偏移，同时通过探索性编程来逐步调整代码，解决可能出现的bug。

这个项目的关键在于计算相对于某个瓦片（tile）的坐标，并处理可能的偏移，避免错误的坐标在处理过程中影响游戏逻辑。提到过在这个过程中没有预设的计划，而是通过实际运行和调整代码来发现问题并逐步优化，类似于探索性编程的方式。

看起来已经在实现过程中取得了一些进展，确保了位置的准确性，并且能够从玩家的姿势（position）获取规范位置，同时也在处理瓷砖坐标的映射问题。虽然还没有完全解决所有问题，但整体方向看起来是对的，并且在探索中取得了一些有意义的进展。

将玩家移动到新瓦片地图

背景与问题：

在开发过程中，主要处理的是游戏角色（例如玩家）在地图中的位置更新问题。具体来说，开发者试图通过规范化位置将玩家从一个瓦片移动到另一个瓦片。这个过程包括计算玩家的新坐标和相应的地图位置。
最初，玩家的坐标是基于原始位置（raw position），而开发者需要将这些坐标转换为标准的、规范化的位置（canonical position）。这些位置涉及到全局的瓦片坐标和当前瓦片内部的相对坐标。
然而，玩家的移动并未完全解决。开发者发现，在处理玩家的新位置时，玩家依然处于旧的地图坐标系（相对瓦片坐标系）中，这导致位置转换仍存在一些问题。

解决方案：

为了正确处理玩家的位置，开发者使用了一个“规范化”的方法，将原始位置转换为规范的位置。规范位置包含玩家在瓦片地图中的 X 和 Y 坐标，以及在当前瓦片内的相对 X 和 Y 坐标。
在转换过程中，开发者意识到，需要使用一些额外的参数来调整坐标，使得玩家的相对位置与全局坐标系相匹配。特别地，开发者需要根据瓦片的尺寸和地图的布局来计算玩家的实际位置。
经过一番调整后，开发者成功地将玩家的坐标转换为正确的规范化位置，确保玩家的位置可以正确地显示在新的地图瓦片上。

调试与问题解决：

在调试过程中，开发者遇到了坐标计算中的一些问题。例如，计算得出的 Y 坐标有时会小于零，导致断言失败。开发者进一步分析了问题，发现这与坐标截断有关。
经过仔细的分析，开发者发现，当计算瓦片坐标时，可能会出现负值。这是因为在玩家越过屏幕顶部时，坐标值变为负数，这是正常现象，但需要确保处理得当。
通过对坐标计算的进一步调整，开发者能够正确处理负值并继续进行调试。

后续步骤：

接下来，开发者计划解决玩家位置计算中的一些剩余问题，特别是如何将玩家的坐标完全转换到世界坐标系中。开发者打算在未来几天继续进行调试，确保所有的坐标转换都能正常工作。
为了验证程序的正确性，开发者计划重新启动应用程序，并检查是否能成功加载正确的玩家位置。

总结：

这个过程中，开发者通过规范化位置（canonical position）和原始位置（raw position）之间的转换，解决了玩家位置计算的问题。但在调试过程中，仍然有一些挑战，如负坐标处理和坐标截断等。通过不断的调整和验证，开发者将继续优化代码，确保地图坐标转换准确无误。

在这里插入图片描述

修复一个BUG

在这里插入图片描述

使用floor而不是truncate

这段话包含了很多关于数学函数、坐标系统、游戏开发过程中的技术讨论以及一些关于开发方法的反思和推测。具体来说，它探讨了几个重要的数学概念和实现细节，特别是关于截断（truncation）和“floor函数”（floor function）的使用，分析了它们在某些情况下的表现，以及如何调整这些功能以满足特定需求。

1. 截断与floor函数的区别

截断操作通常意味着将一个数值减去小数部分，朝着零的方向进行处理。对于正数，它去掉小数部分向零截断；对于负数，它会向零方向“靠近”。这可能不是期望的行为，特别是在需要负数向下取整时。举个例子，当数值是负数时，截断会将 -0.75 变为 0，而不是 -1。
floor函数（floor function）是将一个数值向负无穷方向截断，确保无论正负都会向下取整。因此，floor函数会将 -0.75 截断为 -1，这是我们通常期望的行为。

2. 截断的实际应用

在处理一些坐标系统或地图网格时，可能会需要对坐标值进行截断。比如在一个瓦片地图中，玩家的位置可能会有一个浮动的小数部分，需要将其转换为整数来找到对应的瓦片索引。在这种情况下，使用截断可能会导致某些问题，特别是当坐标值接近零时，截断可能不会产生预期的效果，特别是在负数的情况下。
floor函数作为替代，可以确保在任何情况下都能按预期向下取整，特别是在处理负数时更为精确。

3. 游戏开发中的坐标系统

讨论中提到，坐标系统在游戏开发中非常重要。通过规范化位置，可以将玩家在不同瓦片之间的相对坐标转换为全局坐标。这个过程涉及到将每个瓦片的局部坐标与全局位置进行转换，以确定玩家的精确位置。讨论中提到的“截断”可能是在处理这些转换时所面临的一种数学问题。
游戏开发过程中，坐标系统的设计不仅仅关乎技术实现，也影响到游戏设计的直观性和玩家体验。在开发过程中，通过优化坐标转换和处理机制，可以让游戏更精确、稳定地运行。

4. 游戏功能实现中的障碍和解决方案

在讨论的过程中提到了一些障碍，如当玩家的坐标值出现负数时，截断可能会导致不准确的坐标计算。为了解决这个问题，提到了使用“floor函数”来替代截断操作，从而确保负数值能够正确地向下取整。
还提到了具体的代码实现细节，如何通过编写函数来实现这些数学操作，从而保证在游戏中的位置计算和坐标处理能够稳定进行。

5. 未来工作与改进

在此过程中，提到一些未来工作，包括如何进一步改进数学函数、优化坐标系统的实现，并考虑到如何使用合适的数学函数来实现更精确的功能。例如，可能需要引入额外的数学库（如 math.h）来确保计算的准确性。
还有提到一些关于程序中可能存在的错误（如崩溃情况），并讨论了这些问题如何影响游戏的稳定性，以及如何解决这些问题以确保游戏功能能够顺利运行。

6. 总结

总的来说，讨论的重点在于如何在游戏开发中处理数学函数，特别是在坐标系统和截断、floor函数的使用上。通过对截断行为的细致分析，指出了其在负数处理上的不足，提出了通过floor函数来解决这些问题的方法。这些技术细节是为了确保游戏开发中的数学计算更加稳定和精确。
也提到了一些开发中的难点，如如何设计更好的坐标系统和处理负数截断问题。未来的工作将集中在优化这些数学函数的实现和确保游戏逻辑的正确性。

你能谈谈inline关键字吗？你是否采取了任何策略来确保编译器不会忽略这个请求？

总结上述内容：

在编程时，使用 inline 关键字时，通常并不涉及性能优化的问题，而更多的是为了标记代码，提醒自己未来可能需要对这些函数进行性能上的调整。对于这些函数是否应该内联，并没有直接的性能影响，通常是在代码开发阶段，用来指示自己某些函数可能在将来需要在内联处理中进行优化。

目前，这种标记主要是为了提醒自己，未来当性能调优时可能需要考虑将这些函数内联。但在当前阶段，inline 关键字并不意味着性能优化，而是开发人员对代码结构的注解，更多是为了未来的工作提供一个提示，而不是立即对代码的执行效率产生直接影响。

因此，虽然 inline 关键字在一些情况下可能会带来性能提升，但在日常编程中，其作用主要是作为一种提醒标记，直到进行实际的性能调优时再进行详细分析和调整。

我们是使用C语言还是C++？

在编程时，尽管使用了 C++，但大部分代码其实保持了 C 语言的风格，避免了 C++ 中的许多新特性。大多数情况下，这些代码可以用 C 编译器进行编译。使用 C++ 主要是为了少数几个特性，例如操作符重载和函数重载，这两者是 C++ 独有的特性。

但大部分功能和设计并没有使用 C++ 中的复杂功能，比如继承层次结构或模板等。这些特性并没有被使用，代码的结构和逻辑基本上接近于 C 语言的写法，只有少数几处特性来自 C++。因此，虽然从技术上讲，这些代码可以被视作 C++，但实际上它仅仅在 C 的基础上稍微加了一些 C++ 的特性，并不会使用大多数 C++ 的新特性。

如果最终需要将这些代码从 C++ 转回 C，实现起来非常简单，主要的工作就是去除操作符重载的部分。总体来说，这段代码大多是基于 C 风格写的，虽然使用了 C++ 的一些功能，但并没有深入使用 C++ 的强大功能，几乎所有的设计和功能都可以在 C 语言中实现。

为什么不在输入小于0时减去1，而使用floor()？

在处理负数时，不一定非要直接减去1。虽然使用地板函数（floor）是一个常见的选择，但实际上还有其他方法可以避免截断错误，例如可以先检查输入值是否符合特定的需求。可以根据需求采取不同的实现方式，具体方法取决于环境和要求。

最终的目标是使代码在数学上达到规范的调用，即正确处理负偏移量，而无需做额外的条件检查。这种做法可能会让程序更加高效、快速，尤其是在避免分支判断时，可能会提升性能。

然而，当前的做法并不追求所谓的“黄金标准”，更多的是在探索不同的方法来处理问题。重点在于确保代码能够正常工作，之后再根据实际情况决定最终实现方式。

我以为整数计算比浮点数快，即使CPU有浮点单元。

通常来说，浮点数运算比整数运算要更快。这是因为固定点数运算通常需要多个步骤，而浮点数运算可以在单个指令中完成，尤其是现代处理器在处理浮点数指令时速度和整数指令几乎相同，因此使用浮点数通常不会带来性能上的惩罚。虽然浮点数和整数的处理可能需要消耗相同的处理周期，但浮点数操作的步骤更少，因此总体上浮点数运算会更高效。

例如，在做乘法时，浮点数乘法仅需要一个操作，而固定点数乘法则可能需要两个或更多操作。虽然存在特定情况下整数运算有其独特的需求，但在大多数情况下，浮点数运算是更优的选择。

至于游戏开发，整个过程的每一行代码和实现都有详细的文档记录，可以通过视频存档回顾。这个过程包括了代码的每个输入和背后的原因，为将来的人提供了完整的文档，这也是整个开发过程的一个重要目的。

你是如何决定什么时候将内容打包进结构体的？

在结构包装的使用中，存在两种情况。一种是将多个值打包成一个结构体，以便进行更简洁的调用，这是理想的做法，尤其是在处理像屏幕坐标、点等数据时。如果多个参数通常是一起操作的，打包它们可以使代码更加简洁、高效，避免重复代码，并且使函数调用更易于理解。

例如，在绘制线段的情况下，如果传递的是一对点（x, y），将它们打包成一个点结构并传递是非常合适的。这样做能使代码更加清晰，并且在处理复杂数据时，减少了重复和冗余。

但如果结构包装的做法并没有带来任何好处，反而强制执行这些操作会导致代码复杂化，这就是不好的做法。在一些情况下，强制将不相关的参数捆绑在一起，可能会给调用者带来更多困扰，甚至使得代码变得难以理解和维护。例如，如果你将多个不相关的参数强行捆绑在一个结构中，这可能会让代码变得笨重，并使调用者不得不拆解和重构数据，这样做不仅让代码难以使用，还可能导致更多的错误和重复代码。

总之，结构包装应该是为了使双方都更轻松地完成各自的任务。如果包装使得一方变得更容易，而另一方变得更困难，那这就是一个糟糕的设计决策。因此，结构包装的目标是简化代码、提高可读性和效率，而不是为了形式的强迫。

为什么我们关心屏幕坐标？这不是平台相关的代码吗？

屏幕坐标在游戏开发中是一个重要的起点，因为它是绘制图像的基础。但随着开发的进展，特别是当游戏变得更加复杂时，我们必须逐步转向更抽象的坐标空间，这与游戏世界本身的空间相对应。游戏开发中的关键挑战之一是如何处理这些不同层次的坐标转换，尤其是当涉及到渲染时，像素级的调整会影响到游戏的玩法代码，这会带来额外的复杂性。

从屏幕坐标到游戏世界坐标的转变并不是一蹴而就的，它需要逐步过渡。在这个过程中，虽然一些经验丰富的开发者可能会跳过一些细节，但为了更好地理解和掌握开发过程，逐步探索这些细节是非常重要的。这不仅有助于构建出更好的游戏结构，还能帮助开发者在面对新挑战时找到正确的解决方案。

此外，游戏开发是一种不断学习和发现的过程。每个阶段都充满了新的挑战和新的知识，尤其是对于那些没有做过类似游戏的开发者。通过了解这些过程，开发者可以掌握如何构建出更复杂的系统，而不仅仅是复制现有的解决方案。最终目标是通过这个过程，让开发者能够在未来的项目中自由地创造和设计，而不仅仅局限于完成当前的任务。

你是否会像玩家当前阻挡墙壁那样，让墙壁也阻挡玩家？

在游戏开发中，关于玩家与环境之间的视线遮挡是一个重要的设计考虑。讨论了是否应该让墙壁阻挡玩家的视线，就像玩家的角色遮挡上方墙壁的视线一样。这种设计决定了游戏中的视觉效果和玩家体验，尤其是对于游戏的玩法来说非常重要。为了实现这一点，开发者计划加载位图地图并展示它们，以便可以看到墙壁和玩家之间的视觉关系。

在游戏中，玩家不应被完全遮挡，因为这样会影响游戏的可玩性。设计上，需要确保玩家与障碍物之间的视线被适当的处理，避免影响游戏的整体体验。例如，玩家与墙壁之间的距离不能过远，以免导致无法看到游戏的重要元素，但在某些情况下适当的视线遮挡可以增加游戏的挑战性。

这一决策将取决于游戏的玩法，需要在实际加载并映射出场景后再做出调整。最终的目标是确保游戏的视觉效果能够既符合设计意图，又能保证玩家在游戏中的可操作性和体验。这些调整都是基于实际测试和视觉效果的反馈，确保玩家不会完全失去对角色或目标的可见性。

能否再次解释raw_position和canonical_position？

在代码的阅读和理解过程中，观察到实现某些计算需要一个三层结构。具体来说，这种结构帮助管理地图数据和玩家的位置，特别是在使用平铺地图时。为了追踪玩家在地图中的位置，需要处理一些细节，比如知道玩家在特定瓦片上的位置，并且要记录位置的偏移量，这些偏移量不直接对应像素，因为玩家是持续移动的。

首先，需要了解当前的地图和玩家所在的瓦片位置。在此基础上，还要知道玩家在瓦片内的相对位置。这些信息并不总是与像素对齐，而是更多地与游戏世界中的位置有关。例如，在一个回合制的游戏中，玩家可能在每个回合内移动，这时需要计算相对偏移量。

另外，代码的结构设计了一个坐标系统，用于表示玩家在地图上的位置。这些坐标相对于瓦片地图本身，而非直接与屏幕坐标相对应。游戏中的位置是动态的，可能随着场景的滚动而变化，某些区域甚至可能不可见（例如，Tile的一部分可能始终不可见）。这些细节是通过将玩家的位置相对于地图和屏幕进行处理和映射来管理的。

最终，目标是将这些原始的计算和位置数据转化为更简洁、抽象的结构，使得地图和玩家的位置不再依赖于具体的原始数据。实现这一目标后，可以简化位置管理，并逐步消除那些临时的原始数据，朝着更加模块化和易于管理的设计迈进。

如果不检查玩家移动的方向，而是检查玩家的三个点，这样不是更好吗？

目前，代码检查玩家左侧和右侧是否移动到非空的磁砖上，而有一个建议是是否只检查玩家的侧面。这种做法从效率角度来看似乎不错，但实际上并不会改善代码的行为，也不会带来性能上的提升。在当前的代码结构下，检查玩家的两侧是更合适的方式，因为这种做法已经能够满足需求，且不会影响代码的正常运行。

即使减少检查次数，实际上也不会改变代码执行的结果。当前的结构在检查时并不会额外消耗显著的资源，因此不会因为减少某个函数调用而带来实际的性能改进。反而，简化代码可能会引入更多的判断和路径，增加代码的复杂性，进而提高错误的可能性。

在当前的开发阶段，效率并不是主要关注点，因为这段代码并不会直接影响最终用户的体验，也不会直接被发布到生产环境。此时，优化代码效率并不会带来实际的好处，反而会增加不必要的复杂度和潜在的错误。

只有在架构设计阶段，当代码结构变得足够复杂时，才可能会需要关注效率问题。此时，架构的效率可能会成为考虑的重点，但目前并不需要专门优化效率。现在的关注点更多是探索如何构建和架构游戏，而不是过早地考虑代码执行的效率。因此，尽管有些代码优化建议看起来很有意义，但现在并不需要过多关注这些问题。

为什么不为玩家有一组坐标，将玩家映射到世界位置？

在游戏开发中，是否使用一组坐标来表示玩家的世界位置，这是一个设计选择。一个简单的浮动点坐标系统（x 和 y）理论上能将玩家的当前位置与世界位置直接映射。然而，这种方法存在一个重要的问题：浮点精度限制。在浮点数中，只有有限的精度可以用来表示位置，因此当世界变得足够大，浮点坐标就无法准确表示玩家在世界中的位置。

例如，浮点数只有大约24位精度，因此只能表示非常有限的子像素位置。在一个非常大的游戏世界中，这会导致浮点坐标不能精确地表示玩家在细节上的位置。为了处理这个问题，通常使用整数坐标来表示“瓦片”位置，并将浮动坐标用于表示玩家在单个瓦片内部的精确位置。这样，玩家的坐标不仅可以精确到瓦片级别，还可以处理更大的游戏世界。

例如，如果使用整数坐标来表示玩家所处的瓦片位置（如瓦片地图中的格子），并结合浮动的x和y坐标来表示玩家在当前瓦片中的相对位置，这样可以避免浮点精度问题。通过这种方式，游戏的世界可以无限大，且每个玩家的位置都能得到准确的表示，即使是在非常大的世界中。

这种设计的优点在于，它允许世界大小几乎是无限的，而不会受到浮点数精度限制的影响。通过这种方式，可以创建一个足够大的游戏世界，甚至玩家无法从一端走到另一端，避免了浮点精度不足的问题。最终的目标是确保世界大小足够大，足以满足未来可能需要的巨型世界，并且可以避免因为精度问题导致的错误或不可预期的行为。

总结来说，使用浮点数作为唯一的坐标表示方式并不可行，必须结合整数坐标来表示瓦片位置，浮动坐标则处理瓦片内的相对位置，这样既能确保精度，又能保证游戏世界的规模能够支持庞大的虚拟环境。

使用inline在早期开发中是否有任何后果，比如调试更困难？

使用内联函数在开发过程中通常没有太大问题，特别是在调试时。大多数编译器都提供了关闭内联功能的选项，使得在调试过程中可以避免由内联带来的复杂性。如果在某些情况下，内联函数导致了编译器行为难以理解或调试困难，可以简单地关闭内联功能。编译器通常提供一个开关来关闭内联扩展，这样就能够使得编译器不再进行内联优化，从而解决可能出现的问题。

内联的启用与否完全取决于编译器的设置，通常如果遇到问题，开发者可以轻松地将该功能禁用，而不需要担心它对开发的负面影响。这种控制使得内联在早期开发阶段使用时没有特别的风险。总之，内联的使用对于调试不会构成障碍，因为可以随时关闭，确保开发人员可以回到非内联的实现方式以便于理解和调试。

游戏是否会在没有任何滚动或相机移动的整个屏幕内发生？

在讨论变量命名时，关于使用“x”和“y”作为变量名称的经济性有一定的考虑。一个观点是，应该使用更具描述性的命名方式，尤其是在涉及坐标或位置时，使用“相对x”和“相对y”这样的名称可能更清晰。这样做的好处是，代码更容易理解，对于其他开发者来说也更具可读性，尤其是在复杂的游戏或系统中。尽管有时使用简短的“x”和“y”名称可能更简洁，但在这种情况下，明确表达变量的含义更为重要。

此外，对于代码的命名习惯，首先采用更加冗长且描述性的名字，等到代码开发到一定程度后，如果发现这些名称过于冗长，可以考虑简化或缩短。这种方法有助于避免在初期编写代码时过度简化命名，导致后期难以理解。

游戏设计方面，强调了将游戏内容设计为独立的、易于理解的屏幕，而非依赖于复杂的滚动或镜头移动。这样，玩家可以直接理解和互动的每个屏幕都是清晰且可控的。此外，即使未来可能会有一些微小的摄像机运动或滚动，整体设计理念依然倾向于保持简单明了的单一屏幕设计。

总体来说，命名和设计应以清晰和易于理解为优先，避免过早做出简化，以免影响后续开发中的可维护性。