仓库:https://gitee.com/mrxiao_com/2d_game_2
将调试相机稍微拉远一点
今天的任务是查看地面块的相关内容。首先，在开始之前，决定将调试摄像头稍微拉远一些，因为希望能够看到粉色区域的整体情况。
在渲染组中，昨天介绍了一个概念，即可以使用一个摄像头作为游戏中的摄像头，而另一个摄像头则用于实际渲染，这样我们就能够从俯视角度看到游戏的整体情况，包括所有相关的内容。
例如，屏幕的黄色区域代表了使用常规摄像头时的实际渲染画面，而其他区域则可以显示其他内容，比如当物体进入紫色区域时，它们就被加载进来，进行分页操作。希望检查一下这些分页是否按照预期的方式进行，确保物体在需要时会被加载进来。实际观察后，发现一切看起来都很正常。分页操作似乎按照预期进行，模拟区域确实在合适的时机加载了相关内容，因此目前无需进一步关注。
虽然当前没有紧急需要处理的问题，但还是打算稍后再检查一些细节，确保分页操作能继续顺利进行。总的来说，现在能够看到这一切正常运行，感觉很不错。
增加树木数量
可以考虑增加树木数量。虽然之前为了减轻渲染器的压力，减少了世界中的树木数量，但现在已经接近需要进行优化的阶段，因此可以重新引入更多的树木，这样就不会成为一个大的问题。因此，决定修改树木部分的设置，增加树木的数量。
让游戏变得非常慢
打算让游戏变得非常慢，这样在之后进行优化时，就能感受到自己的进步，觉得自己做得很好，这是一个有趣的过程。
接下来，查看了之前删除树木的地方，发现代码中有些奇怪的部分。决定去掉这些不必要的内容，注意到有个代码段看起来是和楼梯相关的。仔细检查后，发现这部分代码应该是与门相关，而不是楼梯，存在一定的混乱，似乎是世界创建代码中的一些不必要的杂项内容。
查看所有树木并预测今天的工作
在场景中，所有的树木都已经重新呈现，接下来计划检查一些重要的内容，首先是地面块的处理。之前已经进行了一些地面块的工作，设立了一个可以组合地面块的系统，但目前还没有有效使用这个系统。问题出现在我们没有处理多个深度层次的问题，目前的地面块系统只处理了一个平面，随着深度层次的增加，需要引入处理这些层次的机制。
因此，今天的首要任务是开始解决这一问题，确保地面块能够正确地与多个层次兼容。另外，系统还没有适当地处理地面层次，尤其是对于Z轴层次的理解。目前，渲染系统在处理层次时仍显得非常临时，虽然有逐渐引入的层次概念，但渲染系统外部并没有统一的层次概念。因此，接下来需要确保代码能理解这些层次，并在合适的位置存储数据，以便后续处理。还需要思考如何将这些层次引入到光照映射系统中，使其能够适应层次的变化。
同时，虽然目前有了渐变效果，但还没有全面理解和实现这些Z层次的概念，因此这些工作将在接下来的开发中逐步完成。
查看地面
在地面处理系统中，已经有一个可以进行地面合成的系统，并且有一个填充地面块的功能。但是问题在于，尚未考虑如何在正确的时机填充这些地面块，以及如何处理不同高度的地面块。当前的系统仅能处理一个平面，尚未扩展到多个高度层次。
地面缓冲区已经存在，并且每个地面缓冲区都知道自己在世界中的位置。当前的限制是，系统在填充这些地面缓冲区时并未正确考虑高度信息。尽管有一个循环遍历Z轴地块的机制，看起来我们已经为地面创建做了准备，但在渲染时是否实际考虑高度，仍然存在不确定性。
需要进一步检查渲染过程，确保在渲染这些地面块时能够正确处理不同的高度层次。目前的系统在渲染地面时，可能没有完全实现这些高度层次的正确渲染，因此接下来需要处理渲染时如何结合地面缓冲区和不同高度的地面块。
重新启用这个GroundBuffer例程
在检查地面处理系统时，发现很多工作已经做得比预期的要好，几乎所有部分看起来都已经正确，尽管仍然存在一些需要修复的地方。令人惊讶的是，系统的实现似乎比预想的更加接近完成。
为了改进比特图的对齐方式，采用了对齐百分比而非简单的对齐操作。这样，系统能够更精确地将元素居中，对齐时不需要再根据比特图的距离进行计算，这使得整个过程变得更加简化和稳定。
此外，已移除与相机的Z偏移测试相关的内容，现在系统不再使用这种偏移。接下来，可能需要修复一些细节问题，比如处理比特图参数的问题，确保函数调用中的参数数量与预期一致。
给PushBitmap加上一个缩放，查看并注意到Basis没有被清除
在处理地面块时，系统需要决定一个合适的缩放比例。目前，地面块并没有明确的缩放比例，这会导致一些问题，需要进一步解决。
另外，系统在绘制模拟边界时存在一个问题，即基础数据并未清除。这个问题需要在渲染器中解决。通过观察屏幕矩形的行为，发现当移动时，黄色的矩形位置发生了变化。这揭示了一个问题：系统在渲染时设置的基础数据在渲染过程中没有被清除，导致了这种"粘性"现象。需要考虑如何清除或更新这些基础数据，以确保渲染的正确性。
将Basis改回默认
一旦设置了基础数据，在后续的操作中，该基础数据会一直保持不变。因此，当开始绘制矩形轮廓时，需要将基础数据恢复为默认值（假设为零）。目前的 API 需要清理，因为它不太理想，仍在渲染过程中慢慢调整。
同时，地面块的相关工作尚未完成，尤其是"填充地面块"函数没有在更新渲染工作时进行相应更新。需要检查并修复其中的问题，确保它与新的位图渲染方式兼容。此外，绘制地面缓冲区的方式也需要检查，当前的缩放比例不正确，因此需要进行调整。
#if 0禁用GroundBuffer例程，并为渲染的GroundChunks添加可视化
首先，清空现有内容，恢复到合理的工作状态。清除背景颜色并设置为紫色，这样就能在渲染时看到明显的紫色，帮助确认是否正确渲染了内容。接下来，暂时启用一些调试代码，以便查看地面块的位置。
然后，开始检查每个有效的地面缓冲区，并尝试渲染它们。对于矩形轮廓的推送，做了一些调整，把它放到了推送位图调用之前。目的是在推送位图时，能可选地在其上方绘制一个矩形轮廓，来显示位图的边界。此时，矩形的具体尺寸还不清楚，但目标是能够简单地绘制矩形轮廓以便于调试。
查看这些地方并注意到它从未更新GroundChunks的位置
当前渲染地面块的地方可以看到，随着移动，地面块的显示并没有实时更新，这显然是一个问题。这个问题需要优先解决，首先要找出原因。渲染系统应该是持续更新的，特别是在地面块渲染和更新的过程中，似乎没有进行常规的更新。需要检查渲染和地面块更新的流程，确保它们能够在每次渲染时正确反映当前位置的变化。
修复更新，并在世界中走一圈
在更新地面块时，发现原本的地面缓冲区更新逻辑不太高效，导致每次检查所有地面缓冲区，甚至对于同一个地块重复操作。通过修复一个小错误，调整了缓冲区更新的条件，现在地面块随着移动已经能够正确更新，并且看起来表现良好。虽然目前仍有些不完美的地方，整体看上去已经能够按照预期正确选择和更新地面块的位置，这个问题基本解决了。接下来需要继续改进和完善。
找出为什么我们在位图中没有得到任何内容
遇到的一个问题是，地面块的渲染没有正确显示在位图中。问题的根源在于，当前的渲染系统仍然在像素空间进行操作，而希望让其支持分辨率独立。解决方案是将地面块的大小转换为统一的度量单位（例如米），并让地面块与地块对齐，从而避免像素空间的限制。根据现有的世界状态和地块尺寸，将地面块的尺寸设置为与地块的尺寸一致，这样就可以确保渲染更加一致和灵活，避免受到分辨率影响。
让轮廓绘制在正确的位置
地面块的渲染工作已经调整为基于地块的大小进行对齐，地面块的尺寸现在与地块的尺寸一致，确保它们与世界坐标对齐。这使得所有的地面块形成了一个一致的网格覆盖，确保了地面区域的完整性。尺寸和对齐方式已经根据预定的地块维度进行设置，地面块也通过这些调整达到了预期的效果，确保没有问题，整体看起来符合预期。接下来的步骤是进一步确认和测试这个网格的效果。
使FillGroundChunk工作
在渲染过程中，遇到的问题主要与使用的像素单位有关，这与实际需要的不匹配。当前的渲染组处理的是透视计算，但这并不适用于地面块的渲染，因为我们希望地面块在不同分辨率下保持一致，不受分辨率变化的影响。为了解决这个问题，可能需要重新审视渲染组的设置。
核心的想法是将渲染组切换到正交投影模式，而非透视投影。正交模式能确保渲染对象不受视角变化的影响，特别是地面块的渲染，应该使用标准化的坐标系统，而不依赖透视变换。这意味着，渲染过程中，传递给渲染组的坐标应该是规范化的，而不是依赖于透视计算。
为了确保地面块的宽度和高度符合预期，需要利用游戏状态中的世界信息和地面块的尺寸（如 chunk 的实际尺寸，以米为单位）。这些尺寸应该相对于地图的中心进行调整，因此可能需要使用地面块的半宽和半高作为最终的渲染尺寸。
另外，虽然最初可能考虑预计算这些值，但在此过程中决定将计算延迟至实际渲染时，这样的设计可能更灵活和简洁。
让DEBUGLoadBMP能够让我们请求默认对齐方式
在处理位图对齐问题时，考虑到不再需要手动管理位图的中心对齐，建议将对齐的工作交由对齐代码自动处理。目标是在加载位图时，默认对齐方式能够保持一致，且避免每次都手动调整。
为了实现这一点，计划修改位图加载函数，使其在没有特别指定对齐参数时，默认使用居中对齐。可以通过修改 DebugLoadBMP 函数，使其能够支持指定对齐方式。如果提供了 alignX 和 alignY，则根据这些参数进行对齐；如果没有提供，则默认为居中对齐，即 0.5, 0.5。
为了实现灵活性，还考虑提供一个简单的方案，允许通过重载加载函数来设置默认对齐方式。通过这种方式，可以使代码更简洁且功能明确，只需要通过一个简单的调用即可满足大多数需求。如果没有传入对齐参数，则通过 thunk 调用现有的加载函数，并设置默认的对齐值。
最终的修改能够确保位图加载和对齐的工作自动化，减少了对齐参数的显式管理，同时提供了足够的灵活性来处理不同的对齐需求。
继续完善FillGroundChunk
为了简化位图对齐的处理，最终决定将位图的中心对齐方式完全交给自动化的对齐代码，从而不再需要手动管理中心对齐问题。这样，所有加载的位图都会自动使用居中对齐，这减少了对对齐细节的关心。
接下来，处理随机位置时，目标是将物体定位到某个区块内部。为此，可以使用一个随机双边量（bilateral），其通过 Hadamard 乘积将一个半尺寸（half dim）与一个随机向量相乘，生成一个随机的偏移量。这样，生成的随机向量会将物体从区块的中心位置偏移到区块的边缘，确保物体的位置在区块内随机分布。
通过这种方式，可以避免使用复杂的公式，直接通过简单的数学运算就可以得到最终的偏移量。整个过程被简化为计算一个偏移量并将其应用于中心位置，从而实现物体在区块内部的随机分布。
查看它是否能为我们提供更多有用的内容
在尝试渲染地面块时，发现尽管帧率较慢，暗示着地面块已经被正确绘制，但仍然没有显示任何内容。预期会看到填充的地面块，但实际上什么也没有显示出来，这让人感到失望。进一步检查后，发现虽然进行了清除操作，即使没有渲染任何内容，应该至少能够看到一个显眼的颜色（如粉色），但仍然没有看到。
推测可能存在一些根本性的错误，尤其是在渲染这些地面块时。检查渲染命令后，确认使用了正确的位图和位置参数（如 GroundSideInMeters 和 v3{0, 0, 0}，并且位图来自 ground buffer bitmap）。然而，尽管渲染命令看似正确，渲染结果依然没有显示任何内容，而后续的相同命令却能成功显示。
这表明在渲染的某个步骤中出现了问题，可能是与位图的加载或绘制顺序有关。需要进一步调查为什么第一个渲染命令没有产生预期的输出。
验证问题出在位图
验证了一下问题，确认是位图有问题。游戏状态中有一个树的对象，替换了位图后，应该在屏幕上看到树的显示。结果确实看到了树，而且树的缩放看起来也正常，说明我们在正确的位置上绘制了内容。可是，位图没有被填充成调试用的紫色，这点让人困惑，原因不明。接下来，检查了 FillGroundChunk 函数的实现。
尝试进入FillGroundChunk
进入了 尝试进入FillGroundChunk 函数进行调试，发现函数并没有被调用。检查了是否设置了断点，确认了确实没有调用 尝试进入FillGroundChunk。这就解释了为什么位图中没有任何内容。接着，探讨了为什么从未调用过 尝试进入FillGroundChunk，这本身让人困惑，因为如果没有填充地面块，为什么图像上还会绘制出来，这显得不合逻辑。最终，发现问题的根源是某个地方存在错误，导致没有执行 尝试进入FillGroundChunk。
突然意识到：Visual Studio在构建时-O2选项下，无法设置该断点
在调试过程中，发现 Visual Studio 调试器无法在内联函数的调用点设置断点，导致调试未能按预期进行。重新尝试后，检查了正在填充的缓冲区，发现是一个 256x256 的缓冲区。接着，查看了内存状态，发现"行百分比"没有被设置。继续跟踪代码，首先清除缓冲区，接着设置了颜色并执行了渲染输出。通过循环，遇到清除操作后，理论上应该执行矩形绘制调用。进一步查看了输出目标，发现输出目标确实是预期中的缓冲区，宽度和高度不对是问题的根源。
初始化Buffer->WidthOverHeight
发现问题在于位图的宽高没有初始化。进行 FillGroundChunk 时，位图的宽高没有设置，导致了问题。为了解决这个问题，需要确保在填充地面块时，正确地设置缓冲区的宽度和高度，并确保它们匹配。怀疑之前一直认为位图没有维度，实际上是因为宽高未设置。调整后，认为问题得到了改善。接着需要在代码中进行更多的调整，确保缓冲区的清除操作和颜色设置正确，之前误以为应该是粉色，实际上是黄色。最后，调整了优化设置，以提高运行速度。
看看那个帧率
目前，由于地面块的构建过程非常慢，导致渲染效率极低。渲染器在处理这些内容时出现了严重的性能瓶颈，主要是因为每次都会进行过多的重绘，导致帧率极低。此外，由于没有进行排序，不同高度的地面块随机绘制，表现出不合理的效果。尽管如此，至少已经能够正确填充地面块，问题得到了部分解决。
接下来需要调整缩放比例，因为目前使用的是透视变换，这导致地面块在绘制时看起来很小且远离视角。如果需要，可以通过增大地面块的尺寸来临时解决这个问题，但这并不是最终的解决方案。为了确保地面块的大小适当，进行了调整，但仍然发现地面块的尺寸过大，需要进一步缩小。
此外，渲染时由于使用了透视变换而非正交变换，导致绘制的区域无法覆盖所有地面块。需要修改渲染设置，确保所有区域都能覆盖。渲染器还没有完全处理好这些细节，需要继续优化，尤其是地面块的尺寸和层次问题。在进一步调整时，也发现一些黄色背景出现透视错误，这可能是因为背景区域的大小还不够，需要扩大背景块的宽度。
总的来说，渲染性能和地面块尺寸等问题还在调整中，虽然已经有了一些进展，但仍需要继续优化和调整。
只渲染靠近相机的地面层
目前，渲染器性能依然较慢，尽管进行了地面块的调整，仍然需要进一步优化。为了提高渲染效率，考虑在渲染时对地面块进行排序，尽管这一操作最初并不打算做。可以通过筛选出一定区域内的地面块来减少不必要的绘制，避免绘制离摄像机较远的地面块，这样能提升渲染效率。
为了实现这一点，使用了一个条件判断，只有当地面块处于特定的区域内时才进行绘制。如果地面块离摄像机太远，就跳过不绘制。通过这种方式，能够减少渲染时的计算量，进而提高性能。然而，渲染过程依然显得非常缓慢，这让渲染器的性能问题尤为突出，仍需要进一步优化。
此外，虽然进行了调整，但仍然存在部分区域没有正确填充的情况，可能是因为层级深度处理不当或地面块数量过多，导致绘制过程过于复杂。整体来说，虽然已经有了一些进展，但渲染性能和地面块填充问题还需要继续优化。
考虑优化一些渲染器
为了优化当前的渲染性能，可以考虑对地面缓冲区合成进行优化。虽然尚未完成照明部分的最终实现，但对于没有照明效果的位图生成地面块这一过程，进行优化是合适的。优化目标是加快地面缓冲区的构建过程，这样可以显著提高性能。可以先实现一个没有照明处理的简化版本，作为临时使用版本，等照明系统完成后再进行最终优化。
在优化过程中，可以考虑实施一个"逐像素填充"操作，这个操作暂时不处理照明，优化后能够更快地执行。这个优化不仅有助于提升当前渲染速度，还能为后续的其他优化提供参考，帮助理解如何提升整体性能。实现这一优化可以提供一个更流畅的渲染体验，从而避免渲染速度过慢的问题。
总体来看，当前的渲染过程仍然非常慢，因此进行优化是合适的时机。这一优化将有助于提升效率，使得渲染过程变得更加流畅，为后续的其他开发工作奠定基础。
你打算如何处理那些远离层的地面块，它们消失时仍然在屏幕上？你是否需要根据层的距离扩展可见范围？
在处理更远层级的地面块时，可能会遇到它们在屏幕上仍然可见但已经超出视距的问题。为了解决这个问题，可以考虑根据层级的距离来扩展可见范围。一个直觉的想法是引入类似"战争迷雾"的概念，这不仅适用于地面块，也适用于其他所有内容。这种设计可以通过透视缩短效果来实现，看起来会比较酷，同时也能为游戏风格增添一些艺术性。
这种方法的基本概念是，只有一定范围内的内容可见，超出范围的部分会被逐渐模糊或变黑。这样做的目的是避免玩家看到过远的内容，虽然从性能上看，尤其是在GPU路径下，可能不会有太大问题，但不确定这种设计是否会对游戏性产生负面影响。例如，玩家不应看到那些本不应该在当前视角下出现的远距离内容。
目前，可以先保持这种设计，让其自然过渡，待后续观察游戏性是否受到影响。如果发现这种设计对游戏性没有问题，则可以进一步扩展查询区域，比如采用类似金字塔或视锥体的形状。否则，仍然保持矩形区域作为查询范围。
现在地面上的一些元素重复了，原因不明
有些地面元素现在被重复了，这意味着某些地面上的元素在显示时出现了不正常的重复现象。这个问题的具体表现还不清楚，可能是地面元素在渲染时被多次绘制，导致同一元素重复显示。需要进一步具体分析问题的原因，以便确定是否是由于某种渲染或逻辑错误引起的。
我害怕在做游戏时使用排序之类的东西，因为我担心如果有太多物品会变得很慢。我应该担心这个吗？
在制作游戏时使用排序算法确实需要考虑性能问题，尤其是当处理大量项目时。如果项目数量较少，比如只有一千个项目，排序是完全可以接受的；但如果项目数量达到了几千万或更多，排序可能会导致性能问题。因此，关键在于了解可能会处理的最大项目数量，并据此评估是否能够进行有效排序。实际上，任何非 O(n) 的算法都需要考虑其扩展性，了解随着项目数量增多，它们如何影响性能。即使是 O(n) 算法，也需要考虑在项目数量较大时是否会对性能产生负面影响。因此，选择合适的算法时，必须对可能的最大数据量有一个清晰的预估。
我觉得能够看到非常深的地方，比如玻璃或冰面做的地板，应该会很酷
添加冰面或玻璃地板的想法很有趣，特别是在设计中，如果能让玩家从高处看到这些材质，会增加游戏的视觉吸引力。这个想法被认为很酷，因此被加入到待办事项清单中，作为未来的一部分来实现。
内存占用会继续变大吗？现在存储了这么多原始像素数据，难道不担心吗？我们会压缩数据来节省内存吗？我想可能不会，但现在感觉即便是一个2D游戏，我们的内存使用量似乎有点多。你纠正我，如果我错了
内存使用的增加并不一定是个问题，关键在于是否合理使用了内存。如果程序使用内存没有带来实际的好处，尤其是如果只是为了显示一些简单的内容而消耗大量内存，这种情况就会引起不满。然而，如果内存的使用是为了实现更酷的功能，并且有效利用了系统资源，那么这就不算浪费。比如，生成地面块的过程就是一个良好的内存使用方式，因为它让每个世界区域都有独特的纹理，增加了游戏的表现力。如果游戏能够利用更多的内存来实现有趣的效果，那么即使是2D游戏，也应该尝试充分使用硬件资源。总之，目标不是减少内存使用量，而是确保内存的每一部分都有充分的理由，并且最终能够为玩家带来有意义的内容。
地面块是存储在某种数据结构中吗（例如哈希表或网格），还是每帧重新计算？（我在想，地面块知道自己的位置，但它的在数据结构中的位置不就隐含着这一点吗？）
目前，地面块并没有存储在数据结构中，而是保存在一个数组中，并且不会每帧都重新计算。虽然尚未完全实现，但计划将地面块存储在世界结构中，实际上这已经在某种程度上开始了。虽然还没有完全实现，但目标是将这些地面块最终整合到世界结构中，以便更好地管理和使用。
有些喷溅的元素在水平方向上有重复，但并非全部
"水平重复某些斑点，但不是全部"指的是在水平方向上某些斑点被重复出现，但并非所有斑点都会重复。这种现象可能导致某些地面纹理或元素在水平方向上按特定规则或条件进行重复显示，而不是完全复制每一个斑点。
你觉得你现在大概完成了游戏的五分之一吗？
目前游戏的进度大约完成了五分之一，尽管在时间上可能还需要一些时间才能达到这个比例。预计在第200天左右会停止处理引擎相关的工作。从引擎的完成度来看，应该已经完成了一半左右。
关于水平斑点的重复现象，可能是因为目前地面上的斑点数量较少，且没有做任何智能化的处理，导致它们在形状上有所重复。实际上，这些斑点是不同的，尽管它们看起来相似。
当所有的RAM（甚至GPU上的RAM）都被使用时，当游戏切换到后台（切换到另一个应用程序时短暂地）时，所有的内存都需要被交换进出，对吧，甚至是GPU上的内存？还是采用什么策略来防止交换进出大块内存？
在游戏切换到后台时，内存，包括GPU内存，都会被交换进出。这种情况并没有特别的策略来防止交换，因为如果用户在游戏进行时切换到其他应用程序，他们就会接受任何发生的情况。性能问题并不被重视，因为这意味着用户没有专注于游戏。如果玩家选择切换到其他应用（比如Microsoft Excel），那就说明他们不在乎游戏的表现，因此性能会受到影响。
对于游戏来说，理想的状态是能独占系统资源，不被多任务打断。希望在游戏运行时，能够分配所有资源，如果用户想切换到其他应用，那么系统会停止游戏，暂停其资源分配。
问：我们是否在地面块上旋转和缩放喷溅，以获得最大的变化性？
游戏在切换应用时，会暂停并执行一个显著的内存交换操作，而不是继续在后台运行。希望这种方式更像是游戏主机，而不是允许游戏在后台部分运行。
至于地面上的"splats"，目前还没有进行旋转和缩放处理来增加变化性。虽然旋转目前无法实现，因为这些元素已经包含了透视效果，但将来可能会在适当的时机加入缩放功能。
我注意到英雄的头部偶尔会穿过树木（即房间上方的树木），然后会自己修正。这是怎么回事？
英雄的头部偶尔会穿过树木，然后自行修复，问题的原因在于当前没有进行任何排序。现在，所有元素是按照处理顺序直接绘制到屏幕上的，因此会出现某些物体被错误地绘制在前面或后面，导致像树木之间的排序问题。解决方法是，在渲染时对物体进行排序，确保按照正确的顺序绘制，从而修复这类问题。
结束
接下来会进行一些渲染优化的工作，内容将涉及如何测量代码执行时间，并讨论如何进行优化。