仓库:https://gitee.com/mrxiao_com/2d_game_2
查看当前进度
今天的工作重点是继续进行渲染系统的清理。昨天已经完成了一次渲染清理，现在还有一些内容需要继续处理。首先，已经解决了坐标系统的问题，其中世界坐标基本上是正确的，但屏幕坐标出现了翻转的情况，已经修复了这一点，这也顺便修复了反射测试代码中的问题。现在的任务是进一步清理渲染相关的内容，包括Z坐标的处理方式。
另一个重点是明确区分哪些是以米为单位，哪些是以像素为单位。虽然大部分坐标系统都是按米处理的，但目前有些像位图对齐的部分依然按像素处理。这些像素相关的操作需要明确规范，不希望这些部分处理时显得随意。因此，目标是确保所有代码中都清楚地指定了坐标单位和方向，避免未来在使用或修改代码时产生不必要的混淆。
此外，在处理Z坐标时，发现它的处理方式比较随意，没有统一的规范。在进一步整理渲染代码时，需要让Z坐标的处理更加一致，避免它显得不够清晰和规范化。总之，现在的工作重点是确保渲染系统的各个方面在未来能够更加容易理解和使用，不再每次写渲染相关代码时都需要解决不确定性问题，旨在提高系统的可维护性和清晰度。
回到代码
今天的工作重点是继续完善渲染系统的规范，特别是确保所有渲染输入默认为世界坐标（以米为单位），而不是像素，除非特别标明。具体来说，要确保所有涉及像素的输入都被明确标记出来。这一点将帮助避免在后续开发中出现混淆，确保代码中的单位处理清晰一致。
为了更好地管理这些更改，计划将一些内容提取到头文件（.h文件）中。这样做的目的并不是为了实际的代码结构需求，而是为了更方便地查看和检查当前的实现是否符合预期。这类似于在工作中建立一个参考文件，帮助梳理和确保代码的逻辑和结构清晰，避免混乱。
此外，在一些开发环境中（如Emacs和Visual Studio），可以通过折叠视图来帮助管理代码，使得开发者可以只查看函数或特定区域的代码。尽管这些工具在某些情况下能提供帮助，但它们并不总是足够高效，尤其在处理大量函数时，它们往往不能精准地提取出需要关注的部分。因此，将内容集中在头文件中，能够为未来的维护和开发提供更加直观和简洁的查看方式。
将函数提取到 game_render_group.h 并实现移动到.cpp中
在整理代码时，首先创建了一个类似"renderer API"这样的部分，用于将相关的代码整理到一个小节中，以便更容易地进行查看和管理。以下是提到的一些内容：
- PushPiece：这部分代码之前用于某种操作，现在需要将其单独提取出来，以便更清楚地查看。
- PushBitmap：与图像相关的处理，也需要被提取出来，进行详细查看。
- PushRect：这部分代码用于绘制调试矩形，虽然当前并不涉及实际用途，但它是用于调试目的的，且可能在未来的实现中用到。
- Clear：清理的调用，留待之后进一步查看。
- PushRectOutline ：这部分代码是用于测试的内容，暂时也没有实际应用。
移除 PushPiece，改为使用 PushBitmap
在渲染过程中，代码中存在两个函数：PushPiece 和 pushBitmap。目前，二者的功能几乎完全相同，唯一的区别是 PushBitmap 使用了一个 alpha 值，而 PushPiece 没有。经过检查，发现 PushPiece 和 pushBitmap 之间几乎没有区别，只是在维度和颜色参数的处理上略有不同，且 PushPiece 中的维度参数实际上没有被使用。
因此，决定将所有 PushPiece 的调用替换为 pushBitmap，因为 pushBitmap 看起来更为简洁且一致。为了简化代码，将 PushPiece 完全移除。接着，在 pushBitmap 中添加默认的颜色参数，并且处理 alpha 值，确保所有传入渲染器的颜色值都经过预乘 alpha 操作。这样，渲染器将负责处理 alpha 的预乘，而不需要在调用时手动处理，这样的做法能减少用户在使用时的繁琐操作。
在代码调整后，所有 PushPiece 的调用都已经被替换成了 pushBitmap，并且相应的颜色和 alpha 处理逻辑也进行了简化。最后，确认所有的 pushBitmap 调用已经完成，移除了多余的 PushPiece 调用，确保代码更加简洁高效。
指定位图的对齐方式将直接与其关联
在查看传入的参数和对齐值时，发现当前的对齐值以像素为单位，但并没有明确标记出来，因此决定修复这个问题。一个有趣的点是，位图（bitmap）本身可能已经有内嵌的对齐值，因为每个位图都有一个"热点"（hotspot），即在绘制时不是把位图的左上角放在指定位置，而是将其热点放在那里。虽然目前在绘制时使用了对齐值，但这个对齐值并没有直接与位图关联。
考虑到这一点，决定将对齐信息嵌入到位图本身，这样在传入位图时就不需要再传递对齐值了。位图加载时会将对齐信息（如水平对齐和垂直对齐）一起加载，因此在使用位图时不再需要额外传递对齐参数。位图的对齐信息会直接保存在位图对象内，确保在渲染时自动处理对齐问题，从而简化了渲染过程。这样，每次处理位图时，只需要关注位图本身，而不需要额外传入对齐值。
调整并传递对齐方式
在这个过程中，目标是优化位图的对齐方式，具体步骤如下：
- 对齐值的处理： 首先，确保位图的对齐值（
AlignX和AlignY）明确地作为位图的一部分进行设置，而不是在每次绘制时都传递对齐信息。这些对齐值将会"烘焙"进位图数据结构中，确保每次绘制位图时，不需要再次传递对齐信息。
-
修改位图结构： 对于位图加载部分，会添加
AlignX和AlignY字段，并假定初始值为位图的左上角或左下角。具体而言，加载位图时会在位图数据中直接设置对齐信息，而不再在每次绘制时传递。 -
简化绘制函数： 通过修改绘制函数，不再需要传递对齐参数，而是直接使用从位图中提取的对齐信息。例如，对于
PushBitmap，可以移除每次传递对齐信息的步骤，改为直接从位图数据结构中读取对齐值。
-
处理特殊位图： 对于一些特殊的位图（如英雄位图、树木位图等），也会将对齐信息内嵌到位图结构中。在加载这些位图时，可以自动设置对齐方式，减少手动指定对齐的麻烦。
-
清理冗余代码： 在清理过程中，移除了一些不再需要的对齐参数，例如不再需要手动指定对齐参数的地方，代码因此变得更加简洁。
- 默认值和透明度处理： 对于某些位图，默认值和透明度（alpha）处理也进行了调整，确保绘制过程中使用默认的白色或透明度值，这样可以避免每次都手动指定。
总的来说，优化后的系统减少了手动传递对齐参数的需求，代码更加简洁，同时确保了位图加载和绘制时的对齐方式更加智能化。这种做法减少了冗余的代码，并且使得位图对齐的管理更加集中和直观。
在游戏中检查并调查阴影
代码中的其他部分看起来都正常，但阴影的处理却出现了问题。这个问题似乎与阴影的对齐方式有关，因为阴影使用的是与角色相同的对齐设置，而没有进一步调整阴影的对齐方式。
阴影是通过使用角色的位图对齐方式来加载的，但并未专门为阴影指定对齐设置。因此，需要将与角色位图相同的对齐方式应用于阴影位图，以确保阴影能够正确显示。
解决方法是：在加载阴影时，使用与角色位图相同的对齐值，从而使阴影回到正确的位置。通过这种方式，阴影问题得到了修复，最终所有内容都按预期显示。
考虑进一步深入研究 PushBitmap
目前，渲染过程中已经完全摆脱了像素相关的规格，这使得渲染的处理变得更加灵活和便捷。然而，仍然存在一个问题，即在渲染过程中使用的位图推送函数（PushBitmap）处理的某些参数，尤其是关于偏移量（如z轴偏移）、颜色和其他一些配置，仍然显得有些不合理。
例如，z轴的偏移量应当是三维坐标，但当前的处理方式却没有明确表现出这一点，这样的规格看起来比较混乱。此外，一些参数（如EntityZC）似乎是通过某种方式处理的，导致它们缺乏清晰的含义。因此，需要深入分析和调整位图推送函数，以确保z轴位置和其他参数的正确处理。
颜色的处理方式相对来说没有问题，可以继续沿用，但与z轴偏移相关的部分显然需要更精确的定义和实现。目标是进一步优化这些处理，提升代码的整洁性和准确性。
弄清楚我们的 Z 位置出现了什么问题
目前，渲染中的z轴定位存在一些问题，特别是与偏移量的处理相关。当前的结构中，有一个"render_entity_basis"用来处理基础坐标系，这个基础坐标系包括了偏移量（如z轴偏移）和其他参数。然而，这种处理方式显得不够简洁，代码中的一些配置看起来过度指定，甚至有些地方不太清晰。
在处理位图时，存在一些不必要的复杂性，比如z轴偏移量的计算方式，以及如何将这些偏移量与基础坐标系结合起来。为了实现这个功能，实际上涉及了多个计算步骤，包括将偏移量应用于z轴、基于屏幕中心进行比例缩放等。虽然这些操作的目的似乎是为了确保不同元素的位置能够正确渲染，但代码中的某些部分显得过于繁琐且难以理解，特别是乘法因子和其他多余的步骤。
在当前的实现中，一些关键的偏移量（如z轴偏移）在英雄角色和其他对象的渲染中并没有被使用。例如，英雄角色的渲染并没有涉及到这些复杂的z轴计算，而是简单地通过直接的坐标设置来确定位置。因此，有必要对现有的代码进行重构，去除不必要的复杂性，简化z轴的处理流程。
当前的实现可以说是"代码考古"，因为其中有许多过时且不清晰的处理方式，这些方式在一开始可能有其理由，但现在已经显得冗余和不合适。要做到这一点，需要彻底清理和优化代码，使得渲染过程更加简洁且易于理解。
黑板：简陋的阴影
之前的实现中，英雄角色跳跃时，实际上是通过调整角色的"基础坐标"来处理的。这种方式的关键是通过计算一个系数来处理z轴的偏移，以便将英雄的阴影始终显示在地面上。具体而言，当英雄跳跃时，整个角色的位置会随着跳跃而改变，这意味着任何与角色相关的渲染内容，像是生命值和阴影，都会基于这个动态坐标系进行渲染。
为了让阴影保持在地面上，引入了一个系数，用来调整z轴偏移量，使得阴影在角色跳跃时能够正确地固定在地面，而不是随角色的跳跃一起上升。这种处理方法虽然是为了实现特定效果，但显然是一个不太合理的解决方案。
为了更直观地说明这个问题，假设去掉这个系数后再看游戏中的表现，会发现阴影随着角色的跳跃上下移动，这是非常不符合预期的表现。显然，这种做法是错误的，因为它导致了阴影不自然的浮动，这在实际的游戏设计中是不可接受的。事实上，这种做法当初只是一种临时的解决方案，实际上并不适合长远使用。
因此，应该重新审视这个方法，避免这种不合理的"hack"式解决方案，而是采用更合理、清晰的方式来处理角色和阴影的渲染，确保游戏的视觉效果更加稳定和自然。
废弃 EntityZC
在之前的实现中，存在着一些不合理的做法，特别是在渲染过程中与z轴和坐标系统相关的处理。现在已经决定彻底移除这些过时的、不合适的方案，特别是与"实体z坐标"和"EntityZC"相关的概念，这些只是一些不必要的东西，已经在代码中存在了太久。由于最初没有统一的渲染系统，很多东西都采用了"临时拼凑"的方式，导致了代码的混乱和不一致。
现在，决定彻底删除与z坐标和EntityZC相关的所有代码部分，这样的清理不仅让代码变得更加简洁，而且避免了之前那种不合理的实现方式。虽然现在没有处理好阴影和生命值等元素与地面对齐的问题，但这部分的责任不再属于渲染系统，而应该交给调用代码来处理。具体而言，调用代码应该负责确定地面的位置，并确保阴影和生命值等元素始终渲染在地面上，而不是依赖于英雄角色的坐标系进行计算。
这种调整能够确保渲染系统不再被迫处理与地面相关的细节，避免了以前通过"投影回到地面"这种不合理的做法。清理掉这些冗余的代码后，系统将变得更加干净和高效，也为未来的进一步优化和改进打下了基础。
继续调整 Z 代码
在当前的实现中，决定对z坐标的处理方式进行改进，主要是将之前使用的偏移方式改为直接使用三维向量（v3）。这个变化是因为之前的实现中z坐标处理方式不够一致，特别是在转换像素和米之间的单位时存在一些不合理的做法。
首先，决定将所有的坐标（包括x、y和z）统一处理为三维向量，以简化计算和提高一致性。在这过程中，z坐标不再单独处理，转而与x、y一样，直接转换为像素单位。对于之前需要乘以像素转换系数的地方，代码进行了必要的调整，以确保所有坐标都在相同的单位下操作。
另外，之前在处理偏移时，z坐标没有被乘以"米到像素"的转换系数，这显得不合逻辑。现在决定将所有坐标在转换过程中保持一致，以便将z坐标也纳入像素单位中，而不再单独处理。在调整过程中，部分函数的调用也进行了重构，将之前分散的坐标参数合并成一个三维向量（v3），以减少重复代码并提升代码的清晰度。
接下来，代码将继续整合这些修改，确保在整个渲染过程中，所有坐标都以一致的方式进行处理。这不仅使得代码更加简洁，还减少了未来可能出现的错误或不一致的情况。虽然目前还没有完全解决渲染z坐标的问题，但决定保留z坐标的正常值，而不是强制将其渲染为零，这样可以更灵活地控制渲染效果。
运行并检查，发现一切正常
目前的调整看起来都没问题，代码中的空间绘制功能表现正常。蓝色的线条显示了之前定义的区域，这些区域表示玩家可以在其中自由移动的房间。这些线条帮助确定了游戏中可行走的区域，确保了玩家的活动范围符合预期。
将 EntityType_Space 的 Z 位置减半
在渲染空间时，存在一个问题，即是否应该处理z坐标的偏移。当前的做法是直接移除z坐标，但可能需要重新评估这种做法。考虑到空间的体积是基于中心的，有时需要将渲染位置调整到空间的底部，这样会使得渲染更贴近地面，而不是浮动在空间的中间。例如，可以尝试通过减去y值的一半来实现这种调整，从而让渲染的位置更加贴近地面，而不是在空间的中心。这个调整可能会使得空间的视觉效果更加合理，特别是当渲染的是物体轮廓时，确保物体不浮动在半空中。
尝试更合理地处理 Z 值
当前的目标是以更合理的方式处理z坐标的转换，尤其是涉及到米到像素的转换。计划将这种转换只在一个地方进行，以避免冗余和混乱。具体来说，z坐标也需要经过米到像素的转换，就像其他坐标一样，通过将偏移值与转换比例相乘来实现。
在之前的处理方式中，米到像素的转换似乎是在多个地方进行的，尤其是在处理实体基准时。为避免这种冗余，决定将米到像素的转换集中处理，并确保所有的z值都以一致的方式进行转换。这意味着z值将变得更大，因为转换后的比例被应用到了z坐标。
此外，有些地方可能不需要再次进行米到像素的转换，特别是在已经完成转换的情况下，决定去掉重复的转换步骤，这样可以保持计算的简洁性和一致性。
解决一下玩家不能跳动，伙伴不能上下移动的问题
# 黑板：如何概念化 EntityBasis
在当前的设计中，z坐标的缩放处理被用来模拟屏幕上物体随着距离的变化而产生的视觉效果。具体来说，远离屏幕的物体在显示时会被拉近，而靠近屏幕的物体则显得更远。这样做的目的是确保相同的点，距离不同的物体在屏幕上的显示位置不同，远处的物体会更接近屏幕的中心。
然而，实际在渲染时，物体的显示并没有进行此类缩放，因为它们的相对偏移量并没有改变。尽管物体在屏幕上的位置会变化，但它们不会因为缩放而产生透视上的"倾斜"或"倾斜"效果。比如说，树木等物体无论是在画面中的哪个位置，都不会因为距离的远近而开始倾斜。
因此，最终的结论是，基于这种设计，z坐标的计算方式保持不变，物体的显示效果符合实际需求，不需要改变当前的做法。这种思路对于避免过度的视觉畸变和确保物体在屏幕上始终保持正确的方向是合理的。
仅使用 EntityBaseP.z 进行缩放
当前设计中的关键在于使用 ZFudge 值来进行缩放。这表明，缩放操作应该仅在计算敌人基础位置 (EntityBaseP) 时进行，而不应该在总的 z 坐标上应用缩放。z 坐标的总值应当仅在进行 y 偏移时使用，这样可以模拟物体的高度变化，达到视觉上的效果。因此，缩放操作应该集中在处理基础位置时，而不是直接使用总的 z 值进行缩放，这样的处理方式更加合理和准确。
在游戏中查看并仔细检查跳跃
这段代码的工作方式现在看起来是正确的。对于 ZFudge 的调整，现在可以看到实体在跳跃时的变化，能够很好地展示 ZFudge 的作用。同时，实体的位置已经不再出现异常，动作效果也变得自然了。
接下来，可能需要做一些微调，比如调整相机的缩放或者平移，使得更好地观察到 ZFudge 对实体的影响，尤其是在跳跃过程中。通过这样的方法，可以更直观地看到 ZFudge 如何影响实体的渲染和运动。
总体而言，现在的进展是满意的，跳跃效果已经开始体现出 ZFudge 的作用，且实体的显示更加稳定，没有出现之前的异常。这个阶段是一个很好的停止点，没必要继续推进到更复杂的部分。
为什么你在位图中使用 AlignX 和 AlignY，而不是 v2？
使用 AlignX 和 AlignY 代替 v2 的原因主要是因为之前使用的是整数类型的像素坐标，而这对处理起来比较直观。但事实上，这并不是必须的，完全可以将其更改为 v2 类型，尤其是如果希望支持分数坐标的话。
如果将来有需求支持分数坐标对齐，就可以很方便地通过 v2 类型来实现，而不需要额外的复杂处理。虽然目前没有明确的需求来使用分数坐标，但这完全是可行的，因为渲染过程本身已经考虑到了像素单位，所以没有理由不能使用 v2 来处理坐标对齐。
最终的调整就是将原本的整数坐标改为 v2 类型，这样可以更灵活地处理对齐和位置问题，尤其是在将来可能需要更细致的对齐方式时。
角色跳跃时，阴影不应该有一点向上移动吗（因为倾斜的视口）？
如果视角是顶视图，角色跳跃时，阴影应该仍然保持在角色的下方，不应该发生移动。阴影的位置取决于光源的方向，而不是视角的角度。如果光源是来自上方，阴影应该始终在角色下方，无论角色如何跳跃。只有当光源角度发生变化时，阴影的位置才会随之变化。视角角度的变化并不会直接影响阴影的移动，只有光源的角度才会决定阴影的偏移。
如果需要，能让圆形反射一个像树一样的位图吗？
如果想要让一个圆形反射一个位图，实际上是可以做到的。这个反射的位图就是一个环境贴图，里面存储了光照信息，供后续采样使用。如果想证明这一点，可以通过把一个树的位图画进环境贴图中。首先将树的位图绘制到环境贴图的位置，之后如果圆形反射到该位置，就可以看到树的反射效果。这个过程只是简单地反射了位图，而不是通过特殊的棋盘方式或其他特定方式处理。这种反射方法相对简单，只要位图正确映射到环境贴图，就能实现预期的效果。
你能让圆珠从地面上采样吗，还是这项功能还需要时间？
如果想让圆形从地面采样，实际上这并不会太遥远。大约一两周后，等我们明确了地面层的具体实现，就能把光照信息捕获到环境贴图中。不过现在，如果想提前查看效果，可以直接将地面绘制到环境贴图中，并把地面块从缓冲区中取出来进行绘制。例如，可以获取地面缓冲区，并将其绘制到环境贴图上。这样，圆形反射的效果就可以看到，尽管目前反射地面的实现还不是很完美，因为我们的光照系统还没有完全实现。
反射地面并不是最终目标。实际上，这个过程是为了处理光照信息，而不是为了直接渲染反射球体。环境贴图本应该只在光照计算中起到作用，而不是单纯用于反射。在最终实现时，如果反射地面是主要目标，可能会采用不同的方式进行处理，但目前的实现已经有了基础的反射功能。
游戏会支持多少缩放？
关于游戏支持多少缩放，渲染系统允许进行任意程度的缩放。然而，如果缩放过度，艺术资源可能会显得不太适合，因为当像素变得太大时，画面就会看起来很不自然。因此，不希望缩放过远，以免影响视觉效果。
我一直听你说实体，但我猜你说的实体并不是 Entity Component System 中的实体，对吧？
"实体"一词在此并非指"实体组件系统"（ECS）中的实体。可以放心，提到的"实体"并不采用实体组件系统的意义，因此不需要将其与ECS中的实体混淆。
你打算在 ZFudge 代码中添加注释，解释为什么只使用 XY 而不是 Z，避免影响树木、角色等的变形吗？
对于 ZFudge 代码的注释问题，仍然没有确定是否要添加注释。主要原因是需要先进行下一步的工作，具体来说，需要理清如何处理基础的 x y 位移，因为当前尚不确定处理的方式。还有一些细节需要关注，因此目前没有决定是否要添加注释。
我觉得我错过了那一天，但位图是通过法线函数（映射到球体上）进行纹理化的吗？
是的，位图是通过法线函数被映射到球体上的。这是正确的。
我们什么时候会缩小主角的尺寸？
英雄角色的缩放可能会在动画处理之前进行。会等一会儿，以确保没有其他问题后再结束。
感觉我们的边缘有 bug
目前存在一个与边缘相关的 bug，特别是在处理透明度时，边缘没有正确地进行反走样处理，这应该是正常的。还需要检查一些 alpha 相关的内容。
你会使用阴影贴图实现"黑暗房间里的灯"效果吗？
如果在一个三维几何游戏中实现黑暗房间中的灯光效果，使用阴影映射是一种可行的方式。阴影映射的基本概念是，从光源的视角渲染场景，并记录下光源能够看到的表面。然后，当从相机的视角渲染场景时，可以查看是否光源曾经照亮过该物体，如果没有，说明该物体处于阴影中。
但是，由于当前没有实际的深度信息，因此在某些情况下，阴影映射并不会起到预期的效果。
会有某种发射体吗，比如火花？
是的，计划中会有类似火花的发射器，正因为如此，才需要进行当前的光照工作。目标是能够实现这些发射器，因此正在进行法线映射的实验，这是整个过程的关键部分。
如何在 2D 游戏中实现"黑暗房间里的灯"效果？
在2D游戏中实现灯光效果时，目标是通过绿颜色纹理来模拟光的近场效果。由于2D艺术是平面的，没有体积，所以无法像3D中那样精确计算阴影。因此，将通过这种纹理映射来近似光的效果，从而实现类似灯光、火炬、火球等元素的效果。虽然不能做到像3D中那样真实的阴影，但会通过近似技术来模拟这些效果。
在游戏开发中，使用法线函数进行纹理化常见吗？性能如何？还是更常见的是将纹理化应用到三角形表面？
在游戏开发中，使用法线贴图（normal mapping）已经非常普遍，特别是在3D游戏中，它被用来改善光照效果。几乎每个3D游戏都使用法线贴图来进行光照计算。而在2D游戏中，法线贴图使用较少，主要是因为2D游戏通常不是由专注于图形的开发者制作的，所以不会使用复杂的图形技术。然而，2D游戏中，如果有图形方面的深入优化，使用法线贴图的情况也可能出现。
目前，虽然是用软件渲染法线贴图，性能已经相当好，达到较高的帧率。如果换成硬件渲染（例如通过GPU），性能将更好，几乎不会有性能瓶颈。
实体会有投影阴影还是像当前头部那样的斑块阴影？
目前，游戏中的实体投射的阴影都是模糊的阴影，比如角色的头部阴影。主要原因是对投射阴影的处理不满意，因为投射阴影通常看起来不自然。现实世界中，阴影通常是柔和的，尤其是在强烈的阳光下，阴影往往更为复杂，而不是锐利的。为了在光照上做出合理的近似，游戏中的阴影大多会选择柔和的阴影效果。
虽然可能会根据光源的方向对阴影进行一定的调整，但不会采用锐利的阴影效果，因为大多数情况下，光线的表现并不支持这种硬阴影。在一些特殊环境中，如只有一个非常亮的光源且没有反射表面时，可能会看到类似硬阴影的效果，但这种情况在大多数情况下并不常见。
"未优化"？你不是已经开了 -O2 吗？
启用优化选项（如O2）并不意味着代码已经优化。启用O2只是告诉编译器不要做一些不必要的操作，比如每次操作时都将变量从栈中读取和写入，而是应该保持在寄存器中。这可以避免一些低效的行为，但并不会使代码本身更高效。
真正的优化是对代码进行有目的的改进，确保代码在运行时能高效执行。目前，代码并没有经过实际的优化，仍然非常慢。启用O2只是避免编译器增加额外的性能开销，但并不能自动使代码变得高效。因此，启用O2并不等于代码已经优化。
阴影会反射到法线贴图上吗？
如果将阴影加入到光照场中，那么它们会被反射到法线贴图中。如果没有加入阴影，那么法线贴图中就不会包含阴影。简单来说，任何放入光照场的东西都会在法线贴图中反映出来，阴影也不例外。
粒子效果系统会与法线贴图互动吗？
粒子效果系统确实会与法线贴图进行交互，尤其是对于粒子发射器（如火焰效果），这正是设计该系统的目的之一，主要是为了光照效果，因此这些粒子效果会受到影响。而对于其他的情况，是否需要与法线贴图交互则视具体情况而定。
好的，今天就到这里，关闭所有内容。
特别是在渲染方面，认为已经接近完成，但还需要在Z轴部分做一些调整，计划开始绘制不同楼层之间的可视化效果，进一步加强Z轴的处理。接下来几周将主要专注于渲染的优化和调整，以使项目达到理想的视觉效果。