仓库: https://gitee.com/mrxiao_com/2d_game
位置表示的回顾
在之前的工作中，已经实现了将单位从像素空间转移到真实的空间，这样可以确保所有的动作和物体都按米为单位来进行。这个转变让游戏中的物体不再是基于像素的，而是按照真实世界的尺度进行计算。
在渲染过程中，这些真实空间的单位会被转换回像素。这一点非常重要，因为游戏需要支持不同的分辨率，因此不能将所有内容硬编码为特定像素值，而是要在渲染时动态地将其转化为适应当前显示分辨率的像素。
总的来说，重点在于确保游戏在不同分辨率下能流畅运行，而不受硬编码像素大小的限制。
今天的议程
计划开始在瓦片地图结构上进行一些改动，目的是让坐标系统更符合数学运算的习惯，尤其是使得 Y 轴朝上，而不是目前的朝下。这一变化是为了创建一个更标准、易于理解的坐标系统。当前的坐标系统是基于位图的需要，Y 轴朝下，所以需要对其进行翻转。
此外，目标是让城市地图的数据结构更加一致和容易访问。此前有提到这些变化，现在打算在当天完成这两项工作。
首先，计划的第一步是翻转坐标系统，使 Y 轴朝上。考虑到目前并没有具体定义地图相关的信息，完成这一操作应该相对容易。接下来需要思考翻转坐标后对地图和数据结构的影响，特别是如何处理与位图相关的内容。
对于执行顺序的选择，还在犹豫是否先完成翻转坐标的工作，然后再处理其他时间相关的任务和改动。计划查看代码，以决定是否应先翻转坐标，还是先处理其他难度较高的任务。
world_position 和 Y 轴的变化
讨论的重点是改进世界坐标系统以及地图和瓦片的绘制方式。首先，当前使用的是一个手工设置的坐标系统，需要进行调整和重新命名，以使其更符合规范，特别是将“规范化位置”改为“世界位置”，从而简化管理和避免多余的复杂性。这只是一个简单的修改，目标是统一坐标体系，以便更好地控制和渲染世界位置。
接下来的任务是对瓦片的位置系统进行改动，特别是关于坐标系的翻转。目前，坐标系是基于左上角的，这意味着所有瓦片的位置和移动都是从该角落开始计算的。然而，为了更符合数学上更常见的做法，考虑将坐标系统翻转，使得坐标系从左下角开始，Y轴朝上。这意味着需要修改原来的绘图代码以及如何处理瓦片的偏移量，尤其是如何绘制和更新瓦片的位置。
当前的代码使用了从上到下的坐标系统，因此当翻转坐标系时，所有的瓦片图也会被翻转。需要调整绘制的方式，从现在的“从上到下”改为“从下到上”。这是通过改变绘制起点，使用左下角作为起点来实现的，而不是左上角。这样一来，所有的图像和元素会正确地从下到上显示，避免了之前错误的显示顺序。
调整绘制方法后，还需要修正角色移动的代码。由于坐标系翻转，之前的角色运动方向不再适用。具体来说，Y轴的运动需要调整，尤其是在角色向上移动时，Y值应该是负值，而不是之前的正值。修正后，角色能够正确地按照新的坐标系统移动。
最后，通过调整代码来确保所有元素正确渲染，确保新的坐标系统能够无缝地工作。整体流程简单有效，改动的重点集中在如何正确处理坐标系翻转，确保瓦片和角色的运动都能适应新的规则。这些调整使得坐标系统更加标准化，未来的扩展和调整也会更加容易。
修改之前的一个问题
浮动点数问题：位置
这个过程涉及在编程中处理世界生成和精确坐标系统的问题，特别是如何通过浮点数来精确表示位置。
-
坐标系统和浮动的使用： 在这个讨论中，坐标系统的Y轴是向上的，这意味着在编写代码时，所有的世界生成都需要考虑Y坐标向上的事实。位置数据通常会使用32位浮点数来表示，这种数据类型提供了足够的精度来处理坐标系统中的位置变化。
-
分辨率和像素精度： 为了支持颜色混合和抗锯齿等图形效果，每个像素需要至少8位的分辨率。这是为了确保可以精确处理每个像素的颜色及其在屏幕上的位置。这种精度的细节非常重要，尤其是在处理显示器上每个像素的位置和颜色时，确保显示效果不会因为精度不足而受到影响。
-
世界尺寸和分辨率： 在考虑显示器分辨率时，讨论了一个典型的高清显示器的分辨率为1920x1080。通过这种分辨率，可以推算出如果不失去精度，游戏世界的最大跨度大约是68个屏幕的大小，即大约需要5分钟的时间来穿越这个世界。
-
浮点值的理论应用： 通过将32位浮点数应用于世界的位置存储，可以在大范围的世界中保持精确的位置数据，同时也避免了精度丧失的问题。然而，这种方法也带来了游戏设计中的限制，特别是在空间跨度和精度方面。
-
编程技术展示： 最后，整个讨论的核心是展示如何在程序中处理这些技术问题，特别是在处理精确度和坐标系方面。这不仅仅是一个关于如何编程的讨论，而是涉及如何通过技术细节来构建一个更精确、真实的虚拟世界。
屏幕滚动也能正常工作
讨论的核心是如何处理游戏世界的规模和精度，特别是如何通过更高效的方式来管理大规模的游戏世界和位置信息。
-
技术的选择和效率问题： 目前使用的技术虽然提供了较高的精度，但在处理大量数据时不太适用，尤其是在需要处理大规模世界时。使用32位浮点数存储位置和瓦片信息的做法虽然精度过高，但存储16位或8位整数则提供更经济的选择。使用32位浮点数本身并不会带来明显的好处，反而存储16位数会在效率上有所提升。
-
坐标和瓦片索引： 游戏中的坐标和瓦片索引分开存储，通过浮点数操作屏幕空间中的位置，并将所有计算限制在这个空间内。这可以有效管理每个瓦片的相对位置，确保不会丢失精度，甚至可以扩展到无限大世界。
-
无限大世界的设计： 通过使用32位整数来存储瓦片索引，可以在不担心精度丧失的情况下创建一个理论上无限大的世界。游戏可以轻松管理40亿个瓦片，每个瓦片对应60个像素，这使得世界的规模远远超出了玩家能够行走的范围。
-
世界的规模和分辨率： 对于一个由2亿个瓦片组成的世界，这个世界的范围非常广阔，对于玩家来说几乎是不可能全部探索的。通过这种设计，世界的规模几乎是无限的，允许玩家在一个几乎没有边界的虚拟环境中自由探索。
-
滚动和视角设计： 目前讨论的设计考虑了滚动的需求，尽管有些人认为滚动会使编程变得更加复杂和有趣。为了适应这种需求，设计选择了一个更加通用的方案，可以在任何时间启用滚动，同时也不违背游戏的其他设计目标。这种设计允许灵活的视角控制，使得游戏在视觉表现上更为自由，避免了固定视角带来的局限。
-
教育和游戏设计的目的： 在整个过程中，强调了教育的目的，即通过技术的选择和优化，让开发者理解如何在实际应用中处理这些问题，特别是在设计大规模虚拟世界时需要考虑的精度、效率和可扩展性问题。同时，滚动和视角的选择也展示了如何在不影响游戏玩法的前提下进行技术上的优化和调整。
总的来说，整个讨论深入探讨了如何在保持游戏世界的精确度和可扩展性的同时，使用更合适的数据类型和算法来优化性能，使得游戏能够支持大规模、动态的虚拟世界。
平铺块和稀疏存储
在考虑如何处理一个庞大的瓷砖地图时，传统的做法是将其视为多个平铺地图，每个平铺地图代表一个屏幕，并对每个屏幕的内容进行索引。然而，这种方法会受到存储限制，尤其是当瓷砖地图的尺寸达到四十亿×四十亿个瓦片时，所需的存储空间巨大且不切实际。
为了应对这一问题，采用了稀疏存储的方案。这个方案并不存储整个四十亿×四十亿的地图，而是只存储其中有内容的部分。通过这种方式，可以减少存储需求，避免存储大量空白空间。地图被划分为更小的“块”，每个块包含一定数量的瓷砖。只有当某个块包含内容时，才会将其存储。
为了进一步优化存储，块的大小可以根据需求进行调整。例如，选择128×128或64×64大小的块，以便在不同的稀疏性和存储需求之间找到平衡。如果块的大小过大，可能会失去稀疏性，导致存储效率下降。因此，选择适当的块大小对于优化存储至关重要。
这种方法还允许平滑滚动，因为每个屏幕只需查询其显示的地图区域，而不需要预加载整个地图。屏幕只需要处理它所在的区域，并通过查询返回该区域的瓷砖数据。这样，屏幕与瓷砖地图之间不再直接关联，而是通过一个查询机制，动态地从更大的地图中提取需要的部分。
通过这种方式，可以灵活地处理大规模的世界地图，同时减少存储负担，并且支持平滑的滚动和动态加载。
切换：环形拓扑
该段文字涉及一系列技术细节，主要讲述了如何处理世界坐标系、拓扑结构以及一些相关的计算和编程实现。具体内容可以分为几个部分：
-
坐标和世界系统的调整：
目的是将一个二维世界地图中的坐标进行简化和优化，从而去掉不必要的复杂性。通过设置中心点为(0, 0)，并确保坐标值始终不为负数，避免出现下溢问题。为了简化计算，使用无符号整数（如u32），避免使用负值处理，从而使得坐标计算更为直接和稳定。 -
世界是环形拓扑结构：
在拓扑学中，环形世界意味着当离开世界的边界时，可以从另一边重新进入，类似于一个甜甜圈或环面结构。这种结构允许物体在地图的边缘绕回另一端，类似于经典的“无限滚动”地图设计。讨论了世界是否应支持这种循环结构（即环形拓扑）以及如何处理世界坐标的循环问题。 -
偏移和坐标系统：
详细讨论了如何处理坐标的偏移，特别是当偏移为负时，如何确保坐标不会进入不合法的范围（例如，负数或下溢）。通过使用绝对值来处理这些偏移，避免了负数的影响。此外，还考虑了可能需要在某些情况下支持环形拓扑，这样可以允许角色从一个世界边界走出后直接从另一边进入。 -
调试和边界检测：
在调试过程中，需要明确坐标系统的正确性，确保偏移量在合理范围内。通过编写调试代码，检查偏移量是否在预期的范围内，避免出现计算错误或内存溢出。 -
拓扑学的数学背景：
提到了拓扑学，特别是环形拓扑的概念。拓扑学研究的是空间的性质及其连续变形，而不关注具体的几何形状。举了一个例子，描述了环形拓扑如何让世界的边界变得循环，类似于一个甜甜圈或是一个球面上的游走。
总体来说，内容集中在如何设计一个无缝、无负数坐标的世界，如何确保坐标系统稳定，如何实现环形拓扑结构，以及如何处理可能出现的偏移量问题。
从 world_position 提取块坐标
在瓦片系统中，查询的流程基本是通过获取瓦片数据块（chunk），然后在这些数据块内进行查询。需要在世界的位置上执行这些查询操作，这些位置将被映射到瓦片结果。
查询的实现涉及到一种低层次的结构，这种结构通常不会暴露给用户。实际上，这个结构类似于一个瓦片地图，它包含瓦片的x和y坐标，以及在这些瓦片内部的信息。当处理这些数据时，使用了某些瞬态变量，这些变量只在访问过程中存在，且只在特定的情况下才会被使用。
查询的核心目标是使用一个简单的函数，这个函数的实现非常直观，类似于位置的收缩（shrink）。这个过程将数据从较高的层次转移到较低的层次，并且计算过程几乎是免费的。通过这种方法，系统能够避免不必要的开销，且确保绝对位置（如瓦片的x和y）在查询时不会受到干扰。
此外，涉及到块（chunk）时，需要使用“块位移”（chunk pose）来获取相关信息。在获取块数据时，系统会通过传入世界位置来访问瓦片，并根据需要进行相应的位移处理。
为进一步优化性能，一些计算（如位置的位移和索引）会在运行时动态计算，而不会在编译时进行。这些计算包括使用8位和24位值来处理块索引和位置，并在计算时将不需要的部分（如24位值）移除。
最终，系统将通过这些处理完成瓦片的查询，并通过“掩模”操作（如掩蔽掉24位值），来实现高效的查询和数据访问。这样，查询操作在系统内部保持高效，同时避免了过度复杂的处理。
设置测试数据
涉及瓦片（tile）和地图块（chunk）系统的实现。首先，描述了地图瓦片的尺寸设置为 256x256，并探讨了如何处理瓦片地图、块和相对位置的相关逻辑。瓦片块的有效性进行了检查，并明确了在某些情况下是否需要进行空值检查。接着，讨论了如何简化一些检查和验证步骤，因为有些条件可能不再必要，尤其是当瓦片已经验证过是有效的情况下。最后，还涉及了调试和命名问题，强调了代码命名的一些挑战，并提到了一些特定的工程实现细节，如密集查找（dense lookup）和如何管理这些数据块。此外，明确指出了当前的任务和目标没有完全完成，可能会继续进行优化和修改。
实现滚动
这个部分比较绕
