怎样做公司的网站建设,seo点击排名软件哪里好,商业网站制作价格,wordpress默认头像不显示不出来Blackboard#xff1a;增强碰撞循环#xff0c;循环遍历两种类型的 t 值
计划对现有的碰撞检测循环进行修改#xff0c;以便实现一些新的功能。具体来说#xff0c;是希望处理在游戏中定义可行走区域和地面的一些实体。尽管这是一个2D游戏#xff0c;目标是构建一些更丰富…Blackboard增强碰撞循环循环遍历两种类型的 t 值
计划对现有的碰撞检测循环进行修改以便实现一些新的功能。具体来说是希望处理在游戏中定义可行走区域和地面的一些实体。尽管这是一个2D游戏目标是构建一些更丰富的三维结构例如楼层上方的房间可以看到下面的房间或者跳上跳下的台阶等。
进行这些修改并非因为游戏设计需要这些功能而是为了避免回避解决这些更复杂的问题。虽然不一定会在游戏设计中大量使用这些功能但依然要确保引擎技术是顶尖的能够支持这些三维构建尤其是如果未来需要使用到这类技术时能够确保它们无缝集成不会遇到因为忽视这些问题而产生的特殊情况。
昨天讨论了相关的解决方案因此今天会直接开始编写相关代码。昨天我们为这些功能添加了基础架构但还没有进行实际的计算处理。今天的任务就是写出这些计算逻辑并进行实验看看它是否能按预期工作。
接下来将集中精力查看碰撞检测例程尝试在其中进行简单的修改虽然可能未来还会对这个循环进行更大规模的优化和提升。但目前的重点是理解如何在现有循环基础上进行扩展并增加新的功能。具体来说就是要将原本只循环一个 t 值的循环修改为同时处理两个 t 值一个是最小 t 值用于碰撞实体另一个是最大 t 值用于表示空旷空间的实体。这个处理是为了实现一种类似构造性实体几何Constructive Solid Geometry的方式合并不同的空间实体。因此接下来会着重改进 t 值的处理逻辑。
game_sim_region.cpp引入 tMax
在循环的每次迭代中可以看到当前的 t 值tMin这是我们之前用来表示碰撞发生的时刻。接下来需要引入另一个 t 值——tMax表示到达某个最大距离前不碰撞的区域。最初tMax 的值为 0因为在开始时我们并不知道能够在不碰撞的情况下移动多远。
tMax 的引入是为了处理在碰撞检测时能够更好地描述最大可以移动的距离。最初tMax 的值为 0因为在循环开始时没有任何信息可以用来预测接下来能移动的距离。随着循环的进行tMax 会根据碰撞检测逐步更新。
game_sim_region.cpp考虑如何最好地修改此例程
在修改碰撞检测逻辑时首先需要关注的是实体的碰撞检测目前已有的 tmin 处理很好但现在还需要处理 tmax。为了做到这一点首先需要检查哪些实体会影响 tmax然后在遍历过程中进行碰撞检测。如果实体能够碰撞接着就进入进一步的碰撞计算。
在这个过程中首先需要做两个检查。第一个检查是确认是否有可能发生碰撞第二个检查是识别碰撞的类型。对于碰撞计算当前的做法是测试四个边界接下来需要根据这些边界计算 tmin 和 tmax然后选择合适的值。
目前的方案是在测试每个边界时如果检测到的碰撞时间早于预期就更新 tmin如果大于 tmax则更新 tmax。为了实现这一点可能需要对代码进行重复操作但考虑到当前的性能需求不高可以接受这样的做法。
为避免代码重复可以将这些逻辑封装成数据结构通过循环来处理。这种方法有助于简化代码使得逻辑更加清晰而且不会在当前的性能考虑下造成问题。
最终目标是确保碰撞检测能够正确处理两个时间点tmin 和 tmax从而更加精确地计算实体的碰撞情况。
game_sim_region.cpp循环遍历墙壁获取 TestWall 使用的所有数据
为了优化碰撞检测的代码决定将之前手动重复的部分改为循环结构。这涉及到将每个墙壁的测试数据转化为数据结构并通过循环来处理所有的墙壁。这样可以避免代码冗余便于维护和修改。具体做法是通过循环遍历每个墙壁获取对应的碰撞检测参数并调用测试函数进行计算。
首先将每个墙壁的相关参数如位置、大小等存储在数据结构中这样可以避免重复书写相同的代码。通过数据驱动的方式可以让测试函数更灵活地处理不同的墙壁情况。具体的做法是每次遍历墙壁时将相关的测试数据传递给测试函数并执行碰撞计算。
在这个过程中添加了 tmin 和 tmax 的检查。通过这种方式能够同时处理两种类型的碰撞检测一种是最小确认tmin另一种是最大确认tmax。在初步实现时重点放在确保代码结构合理、易于修改而不特别关注性能优化认为在当前阶段优化结构和清晰度更为重要。
一旦结构调整完成后续可以根据性能需求进一步优化代码减少冗余操作。最终的目标是使得碰撞检测功能更加灵活、可扩展并为未来的性能优化留出空间。
game_sim_region.cpp引入 test_wall
接下来需要定义测试墙函数test wall这个函数将使用之前提到的所有参数包括墙壁的坐标RelX,RelY、位置变化delta x 和 delta y以及最小和最大值。还需要确保添加法线normal这是当前代码中未传递的部分。通过这些参数能够进行正确的碰撞检测计算。最终目的是确保碰撞检测过程所需的所有数据都能够正确传递和使用。
运行游戏并确保其仍然正常工作
一切似乎都在正常运行没有发现问题测试过程顺利。所有的功能都按预期工作没有遇到任何障碍。检查了一下各个方面确认了没有异常能够顺利进行后续操作。
game_sim_region.cpp将 TestWall 直接嵌入碰撞循环中
将“TestWall”移动到新的位置不再直接调用它而是直接嵌入代码中。接下来将进行一些修改移除不必要的部分并将操作指针的代码简化。所有的墙体相关内容已经调整并且不再需要指针引用可以直接使用实际的值。计算结果 tMinTest 也直接作为值使用避免了使用指针。整体结构简化清理了冗余的部分确保代码更加简洁明了。最终调整后的代码看起来非常符合预期。
运行游戏并测试碰撞
通过简化代码将相关逻辑合并为一个小循环目前看起来效果不错功能仍然正常运行。测试结果显示大部分功能都保持良好状态但在检测与怪物的碰撞时似乎出现了问题。当前的命中检测可能存在异常尚未验证其是否与最近的改动有关。这可能是由于修改了整体系统的结构或逻辑导致武器如剑在穿过怪物时不再正确触发碰撞检测。虽然这一问题需要进一步调查但目前重点仍然放在其他功能的调整和测试上。
game_sim_region.cpp测试 tMax
在此部分中需要对被认为是内部实体如空白区域实体的测试进行调整。测试逻辑被分为两种类型一部实种针对内体另一种针对不透明的外部实体。为此引入了一个额外的循环用于处理内部实体的测试。具体逻辑包括以下几点 测试分类 对于内部实体计算的是 tMax 测试值确保结果大于零同时记录当前 tMax 的值。对于不透明实体依然使用之前的 tMin 测试值。 逻辑调整 在内部实体测试中判断是否存在比当前已记录的 tMax 更远的命中点。相较于之前测试近距离的命中点现在需要测试距离更远的命中点。 边界约束 为了确保实体始终处于合法范围内需要在检测结束后对位置进行修正保证不会超出内外边界。在处理内部实体时对结果进行微调如通过 epsilon 值以避免与墙体完全重叠。 变量跟踪 引入了 TestWallNormalMin 和 TestWallNormalMax 分别用于追踪内侧和外侧的法线信息。初始值的设置为 tMax 0通过循环更新最终的测试结果。 测试计算流程 每次循环中计算新的 tMax 测试值并在结束时输出最终结果。确保测试点在合法范围内同时跟踪内部和外部边界的法线以便进行必要的修正。
总体逻辑旨在对不同类型的实体进行分类处理确保每种实体的测试结果准确同时维持边界约束避免异常情况发生。
game_sim_region.cpp优化例程
当前的逻辑处理了两种情况一种是会停止移动的碰撞另一种是允许继续移动的碰撞。对于这些情况分别进行了处理。 两种碰撞的处理 停止移动的碰撞更新相关的变量来表示碰撞信息包括法线方向和碰撞位置。允许移动的碰撞判断是否发生了碰撞如果发生更新相关变量例如最大法线方向、碰撞实体和碰撞位置。 移除冗余逻辑 判断后发现部分测试逻辑是重复的因此移除了多余的变量和测试步骤。合并了 TestWallNormal 的处理逻辑将最大值和最小值的计算合并到统一的流程中减少了重复代码。 次级循环的优化 针对次级循环中的逻辑决定将处理移入其中同时简化变量命名使代码结构更加清晰。仅在需要的情况下定义 Min 和 Max 的处理逻辑减少了无用的初始化。 初始化调整 针对最小值和最大值的初始化将其设置为正无穷和负无穷便于后续的比较逻辑。确保在循环开始时重置相关变量以防止遗留上一次循环的状态。 后续逻辑规划 在当前逻辑的基础上需要进一步思考根据不同碰撞情况的具体处理方式。确保碰撞计算结果在符合物理逻辑的前提下对相关实体的行为进行正确约束或调整。
game_sim_region.cpp实现 tMin 与 tMax 的逻辑
当前的目标是确定在哪个时刻碰撞会停止从而决定如何更新碰撞状态和变量。 判断碰撞发生的时刻 tMin 与 tMax 比较通过比较 tMin 和 tMax确定哪个碰撞先发生。如果 tMin 小于 tMax说明碰撞发生在可阻挡的实体上即不透明的墙体导致移动停止。 引入 tStop 变量 初始化 tStop根据碰撞先后的不同决定碰撞停止的时刻。如果是 tMin 较小则设置 tStop 为 tMin如果是 tMax 较小则设置为 tMax。这个值决定了移动的停止位置。 碰撞停止实体和法线 碰撞实体根据碰撞停止的时刻确定发生碰撞的实体并设置为“停止实体”。法线更新根据碰撞的位置更新碰撞法线。此时WallNormalMin 和 WallNormalMax 需要更新为当前碰撞面对应的法线。 变量定义和位置更新 变量的重新定义某些变量如 HitEntity 和 WallNormal之前在代码顶部定义现在需要移动到实际使用的地方。这样可以避免冗余的定义使代码更加清晰。 待填补的部分 当前逻辑中有一些部分尚未完成例如两个 if 变量需要进一步填充以完善测试逻辑。 代码编译状态 当前代码能够成功编译接下来只需要完善未完成的部分添加适当的测试逻辑。 game_sim_region.cpp为 Overlap 和 EntityFlag_Traversable 编写测试
当前的任务是处理空地实体和重叠检测的逻辑并确保在碰撞检测中正确地处理这些情况。 测试是否为空地实体 空地实体检测通过检查实体的可遍历标志EntityFlag_Traversable flag可以非常简单地判断该实体是否为空地实体。如果该标志被设置说明该实体是可以穿越的空地。 在测试前确认实体位置 位置验证在进行移动测试之前需要确认实体确实位于目标实体的边界框内。也就是说必须先检查实体是否在空地实体的范围内才能进行后续的移动测试。 重叠检测的改进 重叠测试移入循环原本的重叠检测逻辑需要被移入循环中并在每次迭代时检查当前实体是否与其他实体发生重叠。这种做法本来应该在循环中进行而不是在其他地方进行。通过这样做重叠检测会更加智能和高效。 处理所有重叠情况 全范围重叠影响所有与当前实体重叠的对象都应该对当前实体的运动产生影响。因此重叠检测不应仅限于某些特定情况而是要涵盖所有的重叠对象以确保运动的准确性。 运动逻辑的复杂性 运动处理的复杂性正确地处理游戏中的运动是一项非常复杂的任务。尽管这部分工作在游戏开发中占据了大量时间但它是必不可少的特别是在处理复杂的碰撞和运动检测时。
鼓励我们不要害怕解决复杂问题
在处理复杂代码时面对混乱和复杂性是不可避免的但通过坚持和深入思考最终可以简化问题。 应对复杂性 在开发过程中复杂的代码常常变得越来越难以管理特别是处理复杂问题时。然而正是通过深入了解并解决这些复杂性可以逐渐找到简化的办法。复杂的代码虽然会导致混乱但这不应成为退缩的理由。相反应该继续推动直至解决问题之后才有可能找到简洁有效的解决方案。很多时候通过艰难的路径走过复杂的阶段最终能够收获更简洁、更优雅的解决方案。 面对挑战时的思维方式 鼓励在遇到复杂问题时继续推进解决即使解决方案不完美。一旦问题被解决就会为之后的优化提供清晰的视角和理解帮助设计更精简、更高效的解决方法。在开发过程中很多时候对问题的理解来自于对问题的深入思考面对复杂代码时应关注最终目标而不是被眼前的难题所吓倒。 重叠检测与优化 在进行重叠检测时需要逐步迭代检查每一轮重叠的实体确保每个迭代都能正确地判断实体是否重叠。对于那些封闭空间的实体应仔细观察它们在检测中的作用。这些实体可能会触发某些事件但可能不应该同时作为触发器使用封闭空间实体和触发器应该是两个独立的概念。 提取重叠测试 为了避免重复执行重叠测试可以将重叠检测逻辑提取成一个单独的函数。这样重叠检测就不必在多个地方重复执行提升了代码的可维护性和清晰度。通过提取重叠测试能够更容易地管理和检查重叠情况确保逻辑的简洁与高效。 临时调整和修复 在测试过程中发现了一个临时的问题——tMax 被设为零时实体无法移动。因此暂时需要将 tMax 设置为一个非零值以便进行有效的测试和验证。
通过这些步骤可以逐步简化复杂的逻辑并为之后的优化和简化打下基础。处理复杂问题时重要的是不要因眼前的困难而放弃最终会通过深入分析和迭代得出更简洁的解决方案。
game_sim_region.cpp改进重叠测试 重叠检测的实现 为了检查重叠需要将实体的 EntityRect 状态移到循环内。这样便可以对两个实体的体积进行检测使用两个嵌套循环的方式。这种双重循环逻辑与之前进行的检测方法相似。在代码中我们检查了两个不同的体积进行重叠测试。如果发生了重叠就处理这个重叠。为了提高效率在检测到重叠时可以立即跳出循环不再继续进行多余的重叠检测。 优化和提取重叠检测 通过将重叠测试从原有的检测中提取出来可以避免多次重复进行相同的操作从而提升代码的清晰度和效率。通过将 overlap 设置为 true 后跳出所有循环这样就可以在检测到重叠时立即结束检测避免不必要的重复检测。 避免冗余操作 在进行重叠检测时避免使用总的体积直接使用之前定义的两个不同体积简化了检测过程。如果重叠发生就在测试时立即跳出循环并完成处理。 细节和编译器优化 在代码中遇到了一个小问题强制赋值给 false 时由于代码中错误地输入了 bool 类型的变量而编译器会发出警告这种警告是因为编译器在处理布尔类型时进行了一些不必要的优化。对此进行了修正避免了编译器进行不必要的优化确保代码更为严谨和高效。
通过上述优化重叠检测被提取成了一个相对简洁且高效的功能避免了重复计算和多余的检查提高了代码的可维护性。
game_sim_region.cpp引入 EntitiesOverlap 用于此重叠测试 重构和简化代码 目标是让所有操作无论如何计算都能顺利通过。首先进行了一些测试确保当前的功能仍然有效。随后决定将代码提取成一个函数以便更简洁和可复用。函数名为 EntitiesOverlap接收两个实体作为参数来进行重叠检测。通过提取这个函数简化了代码使其更具可读性和易用性。 引入压缩导向编程风格 采用压缩导向编程Compression-Oriented Programming的方式即在代码中通过重用已有的逻辑来引导设计。重点在于通过需求驱动设计而不是提前进行复杂的设计。通过重复使用某些功能或代码块逐步改进和优化代码。 增强代码的可读性和简洁性 通过提取重复使用的代码块增强了代码的简洁性使循环和逻辑更加清晰。对函数进行简化和命名优化使得代码更加易读逻辑更加明确。 最终效果 代码变得更加简洁易读循环结构清晰体积也变小了。功能在简化后仍然能正常工作并且易于进一步扩展和修改。
总体来说通过提取函数和优化结构代码变得更加简洁、可维护并且具备了更高的重用性符合压缩导向编程的理念。
game_sim_region.cpp让 EntitiesOverlap 接受一个 Epsilon 扩展区域
以下是对内容的中文总结 引入epsilon精度容差 提出了在重叠检测中引入一个epsilon精度容差值的想法。通过在重叠测试时增加一个epsilon值可以在测试是否重叠时允许一定的“宽容”即扩大重叠区域。默认情况下重叠测试不使用epsilon但可以通过在使用的体积上添加epsilon来实现这一点从而使重叠区域略微增大提供一些容差。 在三维空间中的应用 认为epsilon可以在所有三个维度上应用尽管这种做法有点不常见但这种“放大区域”的方法可以在精确的停止和定位上提供帮助。通过增加epsilon可以允许对象稍微穿过某些边界这对于某些情况下的物体运动检测非常有用。 精确停止与容忍重叠 这种方法的优势在于可以精确地停止物体与房间边界的碰撞同时也能更容易地确定物体是否在一个区域内。这种“宽容”的重叠检测方式对于碰撞系统可能会更有效因为它允许物体稍微穿过边界而不是直接停在边界上从而避免了过度的碰撞。 决定继续实施该方案 最终决定继续实施这一想法即在重叠检测时引入epsilon值使得检测过程更具灵活性和容错性从而改善碰撞处理和物体位置判断。
通过这种方式可以在物体碰撞检测中实现更灵活的处理既能保证精度又能容忍一定的误差从而提高系统的容错能力和稳定性。 修复一个问题
game_sim_region.cpp重新启用 EntityFlag_Traversable 测试并使用 EntitiesOverlap
以下是对内容的中文总结 实现重叠测试 目前的实现将重叠测试移到了一个更简洁的函数中函数通过传递实体进行重叠检测。通过使用EntitiesOverlap可以确定实体可以在重叠区域内移动的最大范围。 引入重叠精度epsilon 在重叠检测中引入了一个重叠epsilon精度容差值用于对重叠区域进行“放大”以便更加宽容地处理碰撞。该epsilon值目前设定为一个较小的值具体数值需要进一步调整和验证可能会在后期根据需要进行细化。 需要创建辅助函数 提到可能需要创建一个辅助函数将epsilon值应用到所有检测体积中从而更有效地扩展每个体积统一处理重叠检测的容差问题。 桌面设置与效率 在编程过程中遇到桌面空间不够的问题觉得工作环境有些局促需要更合适的打字和操作空间以提高工作效率。
总结通过将重叠检测的过程模块化并引入epsilon进行容错处理可以提升碰撞系统的灵活性。此外重叠测试中可能需要进一步优化epsilon值的设定并考虑创建辅助函数来简化代码。
运行游戏并发现我们无法通过 tMax
以下是对内容的中文总结 调试问题 在进行调试时遇到问题尤其是在tMax测试时发现一直无法通过测试。这个问题需要仔细排查并解决。 tMax测试的逻辑 在进行tMax测试时应该将tMax设置为零假设这是实体能够移动的最小值确保测试的起始状态是合理的。 调试过程的反思 在调试过程中需要进行初步的检查以确认测试是否按照预期工作同时避免引入不必要的复杂性。
总结遇到的调试问题主要集中在tMax测试逻辑上需要确保在测试前正确设置其值并进行详细的检查和调试。
game_sim_region.cpp将 tMin、tMax 和 HitThis 移动到循环内 tMax测试调整 tMax测试即最大时间测试实际上是内部测试不需要在外部进行处理。它们可以移动到合适的位置以避免冗余。 tMax测试的目标 目标是测试哪些测试的值最大并确保在执行时获得预期的结果。 问题定位 不确定问题出在哪里可能是EntitiesOverlap函数没有正常工作。 代码循环优化 在遍历两个体积volumes时代码的循环方式存在问题。当前的循环方式不太合适应该进行优化以避免不必要的重复检查。
game_sim_region.cpp重新思考碰撞例程的逻辑 简化重构 在处理实体碰撞时不需要对每个体积进行循环检查。应该一次性检查实体是否重叠而不是逐个体积进行检查。 重新组织代码结构 需要将碰撞检测的逻辑移动到顶部进行判断。首先判断是否是一个“EntityFlag_Traversable”的实体并检查实体是否重叠。如果两者都符合条件则进行碰撞处理。 碰撞处理逻辑 如果实体可以碰撞且重叠就开始碰撞处理。这是需要进行的两个主要检查条件。 epsilon检查 在进行这些判断之前需要引入epsilon精度范围检查这样可以增加容错范围避免精度问题。 最终调整 代码重构后的结构更加简洁且按照逻辑顺序安排检查和处理使得处理过程更清晰易懂。
总结通过简化和重新组织碰撞检测逻辑减少不必要的循环确保代码更加高效且易于维护。
运行游戏并发现它运作得稍微更正常了 调试过程 当前的代码已经开始正常工作但还没有测试的地方可以与“蓝线”进行对比验证。 返回世界创建部分 为了进一步调试将回到创建世界的部分进行检查和调整。
game.cpp仅在第一个房间中创建墙壁以测试新的世界定义
墙体添加逻辑 在添加墙体时决定仅在第一个房间添加墙而不会在其他房间添加墙。如果流的索引为零则添加墙否则不添加墙。 运行游戏并测试碰撞检测 墙体和碰撞 在初始阶段世界只包含第一房间的墙体其他地方没有墙。在与墙体碰撞时系统表现正常无法越过蓝线这符合预期。 滑动和粘滞问题 在测试过程中发现存在一定的粘滞现象角色似乎能做一些不应该做的事情可能与epsilon处理有关。粘滞问题可能是由于没有正确处理epsilon导致角色在空间内滑动时出现不正常行为。 epsilon处理和修复 系统需要重新考虑如何处理epsilon避免这种不正常的滑动现象。可能需要一些时间来解决这一问题。 边界穿越问题 发现角色无法穿越某些边界特别是tEpsilon与重叠epsilon相同导致无法正确穿越应该将它们设置为不同的值。穿越边界的行为不一致在一个方向可以通过另一个方向则不行这表明系统中存在bug。 楼梯相关问题 楼梯的处理方式也存在问题可能涉及到上下楼层的稳定性具体原因仍需要进一步排查。
game_sim_region.cpp增大重叠 Epsilon 的大小 穿越方向问题 遇到一个问题角色无法向后穿越但可以从早期实体到达后期实体反之则不行。这个问题可能与添加顺序有关。这个问题可能是由顺序依赖引起的可能存在一个bug导致某些情况无法正确处理。 重叠测试 尝试让重叠测试更宽松增加重叠epsilon的值以便更容易通过边界。但即使重叠epsilon非常大仍然无法通过边界。不明白为什么在这种情况下团队最大值tMax无法找到更大的值这个问题非常奇怪。 逻辑问题 在测试过程中发现当前的tMax测试与预期不符。当墙体的tMax测试结果较小时仍然接受了这个结果这不符合逻辑无法解释。
调试器逐步进入碰撞例程 调试和检查过程 进行调试逐步查看程序中的情况可能是因为早晨的困倦导致没有看清楚问题的所在。剩余时间不多因此决定仔细查看问题看看能否找出原因。 tMax 测试 执行tMax测试时首先发现测试结果非常大这看起来是正常的因此接受这个结果并继续执行。随后进行碰撞检测并找到与墙体的碰撞。当前测试通过后进行下一次碰撞检测。 碰撞处理 在进行另一次tMax测试时发现一个更近的碰撞理论上应该接受该碰撞为tMax值。然而根据预期这个碰撞应该被忽略而不是作为有效的碰撞结果。
game_sim_region.cpp将 tMaxTest 初始化为当前的 tMax 问题发现 发现问题是因为没有将当前的最大值初始化为已找到的最佳值而是使用了下一个碰撞结果这导致了错误的行为。 修正 修正后确保将值初始化为当前找到的最大值从而解决了该问题。 进一步检查 对于是否仍然需要使用过于宽松的重叠测试进行了疑问并决定进行进一步的检查以确认是否仍然需要该测试。 运行游戏并发现一切看起来还不错但仍然有些不流畅 修正后的结果 修正后程序可以正常通过边界并在边界处停止达到了预期效果。 状态评估 尽管过程有些不稳定但已经接近目标系统现在能够正确地作为边界工作。
QA
你能解释一下 LengthOf(array) 宏和 sizeof 指针的区别吗 数组长度宏与指针大小 在C语言中经常需要定义一个数组尤其是当数组大小已知且固定时。例如处理鼠标按钮时已知鼠标按钮数量固定为五个那么定义一个固定大小的数组更加高效而不需要使用灵活大小的数组这样可以避免不必要的开销。为了避免手动设置数组的大小并保证代码灵活性通常会用一个宏来自动计算数组的大小。这样代码可以根据数组的实际大小进行调整而无需在运行时修改。 宏的工作原理 使用 sizeof 关键字可以获得数组的总大小以字节为单位但它不能直接告诉数组包含多少元素。为了计算数组元素的数量需要将数组的总大小除以单个元素的大小。通过编写宏传入数组并直接计算其元素数量。宏通过 sizeof 获取数组的总大小并通过 sizeof 获取数组第一个元素的大小从而计算出数组的元素数量。这种方法可以确保在使用数组时能够动态地根据数组的实际大小进行调整而不依赖于事先定义的常量或宏。 指针与数组 sizeof 是一个编译时指令可以返回数据类型或变量的大小而不是其存储的值。在使用指针时 sizeof 会返回指针本身的大小或者根据类型返回相关数据的大小。由于 sizeof 不能直接用于数组元素的数量计算因此在使用指针时需要模拟一个实际的值来计算数组的大小。通过虚拟化值类型的方式可以避免引用空指针的问题。这种方法通过构造一个虚拟的值类型来计算指针指向的数据类型的大小而不会实际解析空指针或引用错误。 总结 通过使用 sizeof 关键字和自定义宏能够动态计算数组的大小和元素数量从而避免手动设定固定的数组大小。指针和数组的大小计算方法虽然略显复杂但通过模拟类型和值可以避免编译时错误并确保代码的灵活性和可维护性。 以上总结了数组宏、指针大小及 sizeof 在C语言中的使用以及如何通过宏和指针处理数组元素数量的问题。
你之前提到过的碰撞优化O(n^2)之类的会使用空间实体吗
讨论了用于碰撞检测的空间和之前提到的 O(n^2) 的问题。原本的方案可能并不适合因为它们更多的是用来定义物体的位置而不是直接进行碰撞检测。因此虽然可以考虑采用不同的方法但如果采取这种方式可能需要将现有的结构进行拆分虽然这种调整并不一定是坏事。
其中一个考虑的方向是可以重新构思世界的结构将空间分割的方式进行调整。与其使用现有的实体作为空间分区的方式不如考虑将这些空间分区看作一种超级结构并将其作为专门用于空间划分的结构。这种方法可能会使原来的实体结构不再适用而需要新的专用结构这也是一种可行的选择。
总的来说这是一种探索不同方式来优化空间划分的想法但无论如何调整的方向是灵活的可以根据需求调整方案的实现方式。
sizeof(game_input::Controllers) 在我使用 g 时有效
C的新扩展解决了一些逻辑问题应该能够支持这些功能但实际上在常规C中并不能直接实现。这是一个值得改进的地方虽然新的C扩展提供了一些不错的功能但某些预期的行为还是没有实现特别是在处理某些功能时可能存在一些问题这些问题导致本应正常工作的功能未能如预期那样发挥作用。
像投射物这样的东西我们会扩展它们在 Z 轴上的边界框使它们总是能击中下面的敌人吗还是我们会以某种方式在屏幕空间中处理这个问题
关于投射物体的处理是否将它们的包围盒在z轴上扩展以确保它们能够击中下方的敌人还是通过屏幕空间来处理这取决于是否希望子弹或特殊物体能够飞越或穿过其他实体。这个问题将作为游戏性的一部分在实际游戏过程中根据情况来决定并观察哪种方式最符合预期。此外提到需要修复与弹道相关的bug尤其是剑类碰撞的问题。目前相关的谓词可能存在问题清理谓词时需要一并解决这些问题确保剑类碰撞能够正常工作。
你不喜欢模板吗
对于模板的使用表示不喜欢。原因是对于元编程的喜爱模板在这方面的表现让人感到沮丧。模板的设计方式似乎不符合元编程的需求反而以一种最糟糕的方式实现了很多可能的功能。这种设计让人感到愤怒因为设计者显然没有从实际的元编程角度出发而是从一种抽象的语言设计的视角考虑问题这种视角并不是开发实际软件时的最佳思路。因此决定不再使用模板几乎完全放弃了它们。
像爆炸这种影响区域内所有物体的情况怎么处理因为这不是一个实体与另一个实体的碰撞
对于像爆炸这种影响区域内所有事物的情况处理方式依然是逐一操作。虽然在计算机中没有真正的“同时”影响多个事物的概念操作只能同时针对两个变量进行因此即使有一个实体影响多个实体实际上也是逐个处理的。因此处理爆炸时仍然需要通过循环遍历所有被爆炸波及的实体并对每个实体进行单独的碰撞检测和更新。这种方式与当前的处理方式类似依然是逐一处理影响的对象。
你怎么看待新的 Vulkan API
对于关于Vulkan API的问题之前已经回答过了。简短的回答是由于没有机会查看其实际设计因此无法对其进行详细讨论。只有在能够评估其设计后才能给出更好的意见。在此之前无法提供更多的看法。现在问题已经接近结束这也正好是直播结束的时刻。
