如何为佛山地区的企业定制一个专属的骏域团购网站app？

佛山网站建设骏域,团购网站app制作,重庆南坪网站建设,小说网站开发 公司仓库: https://gitee.com/mrxiao_com/2d_game 回顾昨天的 bug 今天我们继续开发进度#xff0c;进行调试昨天代码的问题#xff0c;主要是关于如何跟踪玩家和敌人在世界中的高度位置。虽然我们做的是一款 2D 游戏#xff0c;但我们希望能够处理多层的房间#xff0c;玩家…仓库: https://gitee.com/mrxiao_com/2d_game 回顾昨天的 bug 今天我们继续开发进度进行调试昨天代码的问题主要是关于如何跟踪玩家和敌人在世界中的高度位置。虽然我们做的是一款 2D 游戏但我们希望能够处理多层的房间玩家可以上下走动这需要处理与三维位置相关的问题。 昨天我们开始调整实体的 Z 坐标确保它们有完整的高度信息并且应该从地面开始位置会从地面向上延伸。然而在调试时发现玩家的角色似乎比预期低应该碰到树木的位置时角色却没有停下来显得像是角色下沉了。我们也观察到角色在楼梯处的碰撞没有按预期进行可能是因为角色的 Z 坐标没有正确计算其高度。 因此有人猜测问题出在没有修正站在地面上的代码忘记考虑实体的高度。也就是说虽然角色的底部位置被设置在地面上但角色的高度应该从该位置向上浮动。因此调整这个问题确保角色位置正确是接下来的重点。 黑板实体的基点与地面位置之间的差异 有人提出了一个很好的猜测问题可能出在实体的位置计算上。我们来看一下实体的高度问题。假设实体是这样的形状侧面图它的 Z 维度代表它的高度。如果我们把实体的高度表示为 Z 维度那么它的中心位置应该在地面上方半个 Z 维度的高度。也就是说实体的实际地面接触点应该是它的中心位置减去它的一半高度。 因此假设地面是某个高度那么实体应该从地面加上它的高度一半来确定其实际的位置。这就意味着我们不能简单地把实体的位置设置为地面而是要加上它的一半高度才能确保它的底部位置正确。换句话说地面实际上应该在中心点下方半个 Z 维度的位置。 这个建议看起来很有道理可能正是导致问题的根本原因。 查看当前如何指定这些概念 在处理这个问题时首先发现了实体的位置计算没有考虑到实体的尺寸尤其是高度Z 维度。具体来说地面高度的计算没有考虑到实体的高度这导致了实体的位置不正确。 我们在处理重叠overlap时地面高度是通过一个插值lerp计算得出的。为了修复这个问题计划在进行重叠测试后根据实体的尺寸调整地面高度。也就是说在计算出重叠后的地面高度后需要再调整它使其考虑到实体的实际尺寸特别是其高度Z 维度。这应该能解决当前问题确保实体的底部能正确地与地面对齐。 game_sim_region.cpp: 将 0.5 * Entity-Dim.Z 加到地面位置 要解决这个问题计划将地面高度调整为原本的地面高度加上实体高度的一半。也就是说在计算地面高度时需要将原本的地面位置上移移动的距离是实体高度的一半。这就是在之前图示中提到的做法通过这种方式确保实体的位置正确。 运行游戏发现问题还没完全解决 调试过程发现当前的碰撞行为有些不合理看起来可能是已经到了顶部楼层导致上下碰撞变得异常。此时需要进一步调试碰撞检测代码尤其是在绘制方面。为了更清楚地理解问题首先可能需要添加一些调试代码来检查当前的碰撞情况确保问题出在哪里。 调试进入计算地面位置的代码 通过调试代码发现碰撞系统中的地面计算已经修复了之前的错误角色的位置现在正确地悬浮在地面上符合预期的高度0.62的实体高度的一半。这解决了之前在预演阶段提到的bug。不过问题可能还在于绘制部分的代码没有完全处理好因此需要继续修复绘制代码。 game.cpp: 查看当前的绘制代码 绘制代码当前使用了一个占位符方法导致调试变得有些困难。具体来说在绘制位图时传入的是位图的左上角位置而不是位图的中心。因此绘制代码中的 DrawBitMap 调用使用了最小角落位置而这与预期的中心对齐有所不同。代码实际上对位图的位置进行了偏移但并未考虑位图的实际大小导致绘制时的对齐问题。虽然目前的代码中已经通过偏移量修正了这个问题但这种方式比较粗糙存在不一致的问题。最终需要决定是修复这个对齐bug还是重新整理代码来改善渲染系统。在不确定时决定暂时不对渲染系统做大幅改动保持现有代码结构。 引入 EntityBaseP 为了正确对齐实体的绘制位置应该将实体的位置调整为基于地面对齐而不是基于其中心位置。建议将实体的当前位置重新命名为 EntityBaseP其位置应为当前实体位置加上实体在 Z 轴上的一半尺寸。这样绘制时就能够与地面对齐因为当前地面位置的对齐是基于这个偏移量的。虽然目前这种方式对大多数实体来说是合理的可能对于飞行类实体不适用但这可以作为初步解决方案未来如果需要可以进一步引入自定义对齐方式。 此外绘制影像时的透明度计算ShadowAlpha也应与此对齐以确保绘制的一致性即影像的透明度应基于调整后的 EntityBaseP 来计算。 运行游戏发现问题似乎已经解决 目前已经解决了绘制和碰撞检测中的一些问题特别是在位置计算和停止点的处理上似乎达到了预期的效果。玩家可以正确地在环境中移动碰撞和停止位置的逻辑也符合预期。 然而仍然存在一个问题就是阶梯的碰撞检测。阶梯不会正确与玩家发生碰撞因为阶梯的高度只达到了地面上方的高度并未覆盖到玩家可能需要攀爬的区域。因此需要解决阶梯的碰撞问题使得玩家能够正确地与阶梯交互。 下一步计划是在阶梯上添加两个矩形一个位于阶梯的底部一个位于顶部。这样做是为了能够更好地控制阶梯的碰撞范围并确保玩家只会在特定的位置与阶梯发生碰撞而不是轻易穿越阶梯的侧面。这个问题的解决需要对当前的碰撞代码进行一些修改和调试。 game.cpp: 给楼梯添加两个矩形 计划在阶梯上添加两个矩形一个位于阶梯底部另一个位于顶部以便更好地处理阶梯的绘制和碰撞。在绘制时需要对这两个矩形的位置进行偏移确保它们准确地定位到阶梯的上下部分。为了实现这一点需要利用已经实现的偏移机制。 在现有的 PushRect 函数中已经支持对矩形进行偏移但是遇到了一些问题。偏移量应该应用于第二个矩形这样可以确保它与第一个矩形不同并且根据 Z 轴的高度进行相应的调整。为了便于辨识底部的矩形会用不同的颜色显示。 然而当前遇到的问题是矩形的偏移似乎没有正确应用导致它们没有按预期位置移动。这可能是因为 Z 轴偏移的处理没有在绘制时被正确使用虽然代码上看起来已经允许了偏移。 下一步需要检查 Z 偏移的计算是否正确并确保在绘制时正确应用这些偏移。这可能需要对现有代码进行一些调试和修改确保偏移量能正确影响绘制过程。 处理 ZFudge 当前存在的问题是ZFudge 只用于计算地面点但没有真正将其应用到 X 和 Y 坐标的偏移上这导致物体在 Z 轴上的位置被抬高但 X 和 Y 坐标没有受到影响。为了更好地处理阶梯和其他物体的绘制想要尝试将 Z 偏移直接应用于 X 和 Y 坐标。 尽管代码的结构比较混乱但希望通过一些调整能在现有代码的基础上获得更多的灵活性而不必深入修改整个系统。为此考虑将 Z 偏移与 EntityBaseP 结合使用使得偏移能直接影响物体的绘制。 实验步骤包括去除现有代码中的某些部分并在需要的位置手动添加 Z 偏移的影响。这可能会导致一些问题尤其是当 Z 偏移被直接应用时可能会引入额外的复杂性因此需要进一步评估这种方法是否合适并决定是否继续使用该方案。 检查对 Familiar 的影响 当前遇到的问题是黄色物体的显示位置不对导致它似乎消失了。这并不是预期的行为因此需要调试和找出原因。尽管尝试了多种方案但仍然没有找到问题的根源正在进一步检查并尝试解决这个问题。 MetersToPixels 被 OffsetZ 预乘 当前问题的原因在于坐标转换中的错误特别是“米到像素”的转换方式。问题出在“偏移Z”值与“米到像素”转换的顺序导致了值被重复乘以“米到像素”这影响了图形的渲染。为了避免这种重复乘法应该在处理 Z 偏移时将“米到像素”的转换推迟确保在正确的位置进行乘法操作。这是当前代码的一大问题进一步的解决方案可能需要重构这部分渲染代码避免继续积累更多的“临时修补”方式。 运行游戏看到效果更接近正确 当前的问题是在楼梯代码的实现上特别是在使用地面位置计算时楼梯的位置仍然不正确。尽管图形渲染已经接近预期但楼梯的渲染和碰撞检测依然存在问题导致其显示位置不准确应该位于玩家角色上方并且在屏幕中心对齐。需要进一步调试楼梯的代码并确保其正确使用地面位置的计算结果。这个问题可能涉及到楼梯的碰撞检测逻辑以及如何正确应用地面坐标的偏移。 game.cpp: 不再添加 OffsetZ 在尝试去除偏移量并直接使用 Z 偏移时图形的显示效果变得更加正确。不过这种方法可能会在长期的绘制过程中引发一些问题特别是在处理等距艺术风格时因为这要求所有的绘制计算必须适应等距视角。尽管目前去除偏移后的结果看起来比较合理但不确定这种方式是否能长期保持稳定需要进一步验证和调试。 黑板ZFudge 的作用 Z 偏移量的作用是根据物体在 Z 轴上的位置对其进行缩放目的是让物体在 Z 轴上越高时离摄像机的距离越远从而产生一种透视拉伸效果。这个缩放效果有助于使远离摄像机的物体看起来更远但也使原本近距离的物体被放大。由于游戏采用等距视角这种处理方式与实际的 Z 轴深度有所冲突因为在等距视角下物体并不直接在 Z 轴上绘制而是以一定角度呈现这就导致了视角上的不匹配。 尽管这种视角匹配存在一定的问题但它是实现特定艺术风格的必要条件并且是 2D 游戏中常见的挑战之一。当前角色可以正常地跳跃到不同的 Z 轴高度且整体效果不错。接下来的工作是继续完善楼梯的碰撞检测确保它能够正确延伸到天花板以上以便玩家可以在楼梯上上下行。这项任务是可实现的且应是当前工作重点。 game_sim_region.cpp: 查看 SpeculativeCollide 为了确保角色只能从楼梯的底部或顶部进入而不能从楼梯的侧面直接进入并跳到任何位置使用了一个名为 SpeculativeCollide 的机制。这个机制的作用是限制角色只能在特定条件下与楼梯发生碰撞确保角色只能沿着楼梯的上下方向行进。 在碰撞检测过程中结合了 Ground tight 信息这有助于判断角色是否接触到楼梯的有效部分。这样可以避免角色从楼梯的侧面进入确保楼梯的碰撞处理仅在角色位于楼梯的底部或顶部时才生效。 引入 GetEntityGroundPoint 为了简化代码并避免重复计算决定引入一个名为 GetEntityGroundPoint 的调用函数。这个函数将返回一个实体的地面位置并且通过将实体的Z维度偏移一半来调整该位置确保地面位置正确。这样一来所有需要计算实体地面位置的地方都可以统一调用这个函数避免在多个地方重复计算提升代码的可维护性。 例如在需要获取某个实体的Z位置时直接调用 GetEntityGroundPoint这个函数会自动处理位置的偏移。通过这种方式可以更方便地修改和管理地面位置的计算方式而不需要在代码中逐一修改所有相关部分。 使用 GetEntityGroundPoint 设置 EntityBaseP 和地面位置 当前正在考虑如何使用 GetEntityGroundPoint 来计算实体的偏移量并调整实体位置与地面位置的关系。具体思路是通过获取实体的位置然后根据其 Z 值计算地面位置再调整以实现正确的偏移。 黑板计算地面位移 这段内容的核心思想是通过将实体的位置与地面位置进行比较计算出它们之间的偏移量从而确保地面正确对齐实体的位置。具体步骤如下 实体位置与地面位置的差值为了避免在不同地方重复计算地面位置决定使用 GetEntityGroundPoint 函数来获取每个实体的地面位置。然后通过计算实体位置与地面位置的差值即实体位置减去地面位置来得到偏移量。 计算偏移量这个偏移量是一个向量表示从当前地面位置到实体位置的距离。通过这个偏移量地面高度可以被正确调整。 通过向量运算调整位置使用向量减法来计算从地面到实体位置的偏移量确保实体与地面正确对齐。 总结来说目的是通过集中计算地面位置简化代码中的多个计算并确保以后修改时能一致地应用。 运行游戏发现现在可以上楼了 现在修复了上楼的代码但下楼的问题依然存在。这是因为碰撞检测部分已经正确工作或者至少已经调试了尽可能多的已知问题。修复后碰撞检测不再与那些最大值位于地面上的物体发生碰撞因为它们实际上处于我们下方的地面层。这意味着在地面层上方的物体不会再被误判为碰撞对象。 game.cpp: 使楼梯延伸到地面之上 目前楼梯的碰撞检测已经正常工作但存在一个问题我们无法从上方进入楼梯。问题可能出在楼梯的高度设置上楼梯被设置得太高导致我们无法顺利进入。为了改进这一点计划是让楼梯稍微超出地面层的一定高度这样可以确保我们在移动过程中能够与楼梯发生碰撞避免无法进入的情况。 此外之前提到的“步高”问题也需要处理考虑到这是影响楼梯交互的一个因素。现在楼梯的顶部虽然可以与玩家正确碰撞但仍然存在一些小的高度差可能导致玩家不能顺利进入。这些细节需要进一步调整。 黑板理解 StepHeight 目前楼梯的碰撞检测存在一些问题特别是在上下楼梯时的交互表现。现有代码的逻辑是如果玩家在接近楼梯时步伐与楼梯的高度差大于一定值例如0.1米就不能直接跳上楼梯而必须从合适的高度进入。然而这个高度差和玩家与楼梯的交互方式存在一些问题尤其是当玩家尝试从楼梯侧面接近时碰撞和过渡效果并不理想造成了一些“跳跃”或不平滑的过渡。 为了解决这个问题计划对现有的楼梯模型进行调整。当前的楼梯实际上是以坡道形式实现的而不是传统的阶梯。这意味着楼梯的碰撞矩形应该具有更大的范围以覆盖整个坡道区域从而避免因碰撞区域不够大而导致的跳跃或穿透现象。然而计算地面位置时并不应该使用整个楼梯的碰撞矩形而应仅使用一个较小的参考值例如楼梯的单层高度。这样就能确保玩家能够更加平滑地与楼梯交互避免过高或过低的触发问题。 这种方式能够让楼梯的碰撞检测更具灵活性也能为未来的调整提供更多可能性。 game_sim_region.h: 在 sim_entity 中添加 WalkableHeight 为了更好地处理楼梯的交互考虑了根据不同的楼梯高度变化来调整碰撞检测。当前的方案是通过调整最小Z值来确定“可行走高度”这意味着在不同楼梯区域玩家与楼梯的交互将根据楼梯的高度变化来确定是否可以通过。这种方法的目标是确保玩家能够在不同的楼梯高度之间平滑过渡而不受不必要的碰撞限制。 为了避免在不同楼梯区域之间有太多重复计算建议引入一个“可行走高度”的概念这个高度可以通过结合当前楼梯区域的最小Z值与楼梯的实际高度来计算。通过这样的方式楼梯的碰撞检查就变得更加高效和一致。同时在实际开发中这一机制也便于日后的调整因为只需要在某些区域对“可行走高度”进行修改即可无需重新编写碰撞逻辑。 这种方法能使得楼梯的交互更加灵活且符合实际需求尤其是在多层楼梯或不规则楼梯的情况下可以避免由于碰撞体积设置不当导致的玩家行为问题。 game.cpp: 在 SpeculativeCollide 中使用 WalkableHeight 我们决定在添加楼梯时能够指定其上升的高度这样可以确保楼梯的碰撞区域与可行走区域分离。具体来说我们会将 entity_sim 结构中的 walkable_height 设置为游戏状态中世界瓦片的深度以米为单位。这样楼梯的碰撞矩形高度就与可行走区域的高度分开了这有助于在处理楼梯时更好地控制玩家的行为。 运行游戏尝试楼梯 在进行楼梯调试时虽然楼梯的上升部分正常工作但在尝试下楼时出现了问题。具体来说存在一个明显的台阶突起导致无法顺利下楼。尽管其他部分的碰撞检测已经正常但在楼梯的最底部仍然有些问题。需要进一步检查并修复这个 bug以确保下楼时不再遇到这种障碍。 game_entity.h: 引入 GetStairGround 在进行代码调试时发现了两个不同的地面计算方式这可能是导致问题的根源。需要创建一个函数来统一计算地面高度。通过改进现有代码可以避免不一致的计算减少潜在的 bug。 进一步的计划是完善实体系统逐步增加更多的实体特定数据这样在后续改进和维护时能够更容易地处理各种不同类型的实体。尽管目前的实体系统尚未完全构建但现有的基础已经具备扩展的潜力。为了避免重复的错误代码中的一些假设需要被固化保证系统的一致性和稳定性。 同时涉及地面点计算的问题也得到了一些澄清发现并不是 bug而是代码在某些情况下由于假设不一致导致的暂时性错误。在重构时需要将 GetEntityGroundPoint 和相关计算步骤整合确保所有计算使用一致的地面点。通过这些改进整体的实体系统和地面计算方法将更加健壮后续的开发和调试也会变得更加高效。 game_sim_region.cpp: 将 HandleOverlap 和 SpeculativeCollide 改为使用 GetStairGround 在这段内容中代码的目标是将现有的重叠处理逻辑简化为调用 GetStairGround 函数来获取楼梯的地面高度并保留原有的 GetEntityGroundPoint 函数调用作为备份以防未来需要对 X 和 Y 方向进行调整。以下是详细总结 简化代码原本有多个处理重叠的代码段现在决定使用 GetStairGround 来计算楼梯的地面高度。这样可以避免重复代码并集中处理楼梯地面的计算。 保留备份尽管不太可能仍然保留对 GetEntityGroundPoint 函数的调用以防未来需要在 X 和 Y 方向进行位置调整。这样做可以增加代码的可扩展性和容错性。 移除冗余代码在楼梯的重叠处理部分移除了不再需要的代码特别是与重叠处理无关的内容如检查两个条件的代码。这些检查似乎是多余的因为处理楼梯的唯一标准应该是“需要跨越的高度”。 确认类型为了避免发生不必要的错误增加了类型检查确保调用 GetStairGround 时传入的实体确实是楼梯类型。这样可以防止错误调用其他类型的实体并导致程序崩溃。 待处理问题代码中提到还存在一些可能没有完全实现的部分并标注为需要进一步工作的地方。这可能是为了后续的优化和功能扩展做准备。 整体来说目的是通过精简和重构现有的重叠处理逻辑让代码更加简洁、清晰并提高其可维护性同时为将来可能出现的需求留有余地。 运行游戏发现问题得到解决 目前的情况看起来进展不错已经有很多功能能够正常工作虽然仍有一些不完美的地方。地面高度的计算是一个主要问题但整体效果已经有了显著的改善。不过仍然出现了一些异常尤其是某些地方的表现并不符合预期可能是存在bug。比如在角色下楼梯时某些动作没有完全按照预期进行需要仔细检查并修复。 game_sim_region.cpp: SpeculativeCollide 需要知道是上楼还是下楼 当前遇到的问题是关于处理楼梯的碰撞和上下楼梯的地面类型。需要解决的核心问题是如何让碰撞系统能够正确处理从楼梯上移开或走上楼梯的情况确保能够识别楼梯之外的地面类型。这涉及到对地面高度的规范化并且在碰撞循环中考虑高度变化避免不合适的高度变化导致物体无法正确移动。 接下来计划解决的问题是在碰撞系统中加入处理地面层级的概念使得碰撞可以正确处理跨越楼梯等地形的情况。同时还需要进一步确保不同的地面高度在不同的区域能被正确处理确保碰撞系统能准确判断和限制物体的移动范围。 总的来说今天完成了预期的一些任务但仍有一些细节需要进一步完善尤其是在碰撞和地面处理方面。计划在明天继续深入解决这些问题并对地面层级进行更细致的设计以确保系统能够正确处理不同高度的过渡。 问答环节 问你在 Linux 上使用 Clang 吗 在Linux系统上使用clang编译器在Windows上则使用Visual Studio的编译器。同时虽然他们曾经在Mac上进行开发但目前已经不再频繁使用Mac进行项目发布因此对Mac的开发环境不再熟悉。 问从零开始自学 C 的最佳方法是什么 关于如何从零开始自学C程序员建议最好的方法是通过大量的编程实践来学习。首先可以从一些基础的教材入手比如《C程序设计语言》这本书KR这本书对于理解C语言及其思想非常有帮助。除了阅读书籍观看相关的编程直播观察别人是如何编程的尝试模仿和理解这些操作也是一种很好的学习方式。 程序员提到自己学习C的经历已经过去很多年因此不太记得具体的学习材料且也不清楚现在是否有特别推荐的入门教程。不过持续编写代码和解决问题是自学C的核心。 问你知道 Voxpel 编程吗 对于Vox pel编程程序员表示自己不太清楚这个术语的含义推测它可能与Voxel体素有关。虽然不熟悉Vox pel引擎的编程但他知道如何编写体素引擎。 问你打算把家里的楼梯换成坡道吗 我们在游戏设计中加入了一个能够平滑上下来回滑动的楼梯感觉非常好甚至比传统游戏中的楼梯更顺畅。最初并没有打算加入坡道但由于这一滑动体验太令人满意我们决定保留这种设计并在未来进一步完善。我们也注意到游戏中常见的2D楼梯处理方式通常角色会触发固定动画并转屏切换而我们的设计则没有这种切换感而是通过平滑的滑动让玩家能够自如上下楼层带来更好的体验。尽管现实生活中不会实现类似坡道但我们决定在游戏中继续沿用这一创新设计。 问你是怎么让 Visual Studio 调试视图的右侧垂直分割的 如何在 Visual Studio 调试器中将窗口分割成垂直布局。方法很简单只需将窗口如模块窗口拖动到屏幕上。当拖动窗口时会看到一个类似指南针的指示符若将窗口放置在其中一个区域窗口会自动对齐。如果放置在其他区域则会分割窗口。这样可以根据需要自由调整窗口布局例如创建多个窗格或者将窗口分为上下或左右不同的布局。 然而在旧版本的 Visual Studio如 2008 版中存在一个严重的 bug尝试对窗口进行停靠时会导致程序崩溃而微软在其知识库中明确表示该问题不会修复建议用户避免使用这一功能。但在较新的版本如 2013 版中这个问题已经解决不会再发生崩溃。 问为什么你在代码中使用这么多魔法数字 这里的“魔法数字”指的是代码中未经过清晰命名的常量值这些值往往在代码中没有解释其含义导致代码不易理解和维护。 问你怎么看待友元类 在开发中认为使用 friend 类是多余的觉得会浪费打字。由于不使用 private因此也没有必要使用 friend。 问这是不是变成了反向 Doom几乎是 2D 渲染 3D而不是 3D 渲染 2D 在讨论游戏渲染时提到了一种“2D渲染在3D中”的设计方式类似于经典的《DOOM》中的“2.5D”视角但方式有所不同。《DOOM》采用了近似的3D效果来表现墙面实际上仍然是2D渲染而我们则是通过精灵分割来实现精灵本身没有倾斜而是采用了3D定位系统。这种设计可以理解为“反向DOOM”或“2D渲染在3D中”。 我们认为确保3D基础结构的稳固非常重要因为这可以避免开发过程中出现意外问题减少临时处理的需求。虽然2D渲染方式可能有点“hacky”但考虑到实现成本相对较低这种方法仍然是值得尝试的。通过提前实现扎实的3D基础结构能够确保后续开发中不会频繁遭遇问题避免不断进行临时的解决方案。 问如果你上楼进入一个封闭的房间最上层会不会渐变显示 在讨论游戏中的楼梯和房间的渲染时提出了一个问题当玩家从楼梯上走到一个封闭的房间时最上层是否应该渐变显示。对此猜测可能会采用渐变效果来解决这个问题但也表示目前还不确定具体的实现方式。由于这个问题还需要进一步的实验和调整因此暂时没有最终的解决方案仍然需要一些尝试和探索。 问你计划什么时候对精灵进行 Z 排序 在讨论精灵的Z排序时表示计划在渲染器实现时进行但预计这一部分的工作不会在短期内完成可能还需要一段时间几个月后才会开始着手。 问你为什么在代码中使用这么多魔法数字为什么有这么多 #define 在讨论代码中的“魔法数字”时解释了为什么有些数字没有使用宏定义#define。如果某个数字只在局部使用且没有在其他地方引用那么就没有必要将其定义为宏否则会污染全局命名空间。如果某个数字在多个地方使用那可能就是一个需要改进的地方可以提出指出看看是遗漏了还是有其他合理的原因。 问你打算使用高级着色器技术吗如果是你打算使用哪些 在讨论是否使用高级着色器技术时表示计划使用一些高级着色器技术但目前还为时过早具体细节将在未来的开发中逐步实施。 问看起来我错过了一集你在其中实现了从高层看到低层。你记得那是在哪集吗将来地板会保持透明吗 在讨论渲染器时提到地板不会保持透明尽管目前地板是透明的这样做比较方便。未来会添加地面可能会首先加入一个占位符地面而不是保持透明。同时还需要处理如从上层下降到下层时如何渐变处理上层的显示效果等问题。这部分的工作计划在接下来的开发中进行但具体细节仍在考虑中。对于何时实现这个功能也没有明确的记忆或时间点。 问如果我没记错的话早期我们开始使用角色底部中心位置进行碰撞检测然后改为中心位置并且在 X 和 Y 方向上有所偏移。现在似乎又回到了使用中心 X 和 Y并继续计算底部中心位置。你认为是否需要将这一点整合起来 在讨论碰撞检测时提到最初使用的是角色底部中心位置来进行碰撞检测后来调整为中心位置偏移了x和y坐标。现在似乎又回到了使用中心x和y坐标的方式同时保留了底部中心的位置。关于是否需要将这些方法合并认为目前的做法更合理因为统一处理x、y和z坐标更加简洁避免了不同坐标轴上采用不同的处理方式这样可以简化数学运算避免在处理复杂的碰撞检测时出现混乱。如果让碰撞检测的不同部分如Minkowski和干涉测试在x、y和z上使用不同的方式可能会增加数学复杂度影响效率。因此统一处理所有坐标轴并单独处理与地面相关的偏移似乎是更明智的选择。尽管如此这个决定仍然有可能在未来被重新评估。 问森林中间漂浮的头是怎么回事 森林中飘浮的头部是一个“伙伴”它会跟随玩家四处移动。 问能解释一下 game.h 中的这一行吗ControlledHeroes[ArrayCount(((game_input *)0)-Controllers)];看起来你在强制转换一个空指针并引用它 无法直接获取数组成员的大小因此需要通过一些技巧来绕过这个限制。目标是计算数组的大小但C语言不允许直接对类型或成员使用sizeof必须使用实际的变量或值。因此采取了一个技巧性的方法使用一个空指针并将其强制转换为正确的类型模拟对该数组的引用从而间接计算数组的大小。这种做法虽然看似不太优雅但由于C语言的限制这是目前的解决方法。 问为了绕过 Mischief 缩放问题你能先找到想要的缩放级别然后在四个角上画四个点接着再回来对齐这些点到角落吗 关于Mischief缩放问题的解决方案。提出了一种方法即找到需要的缩放级别后在每个角落绘制四个点然后回来时通过对齐这些点来恢复视图。但这种方法被认为不太方便因为每次都需要找到这些点。目标是找到一种可以直接设置缩放的方式而不需要不断地定位这些点。 你可以使用 C 的 decltype 或 typeof 来找出 ArrayCount 在讨论C中使用decltype和typeid等特性时提到尽管这些功能可以帮助获取类型信息但由于它们传统上并不总是得到很好的支持因此尽量避免使用这些特性尤其是对1990年代的C语言风格更为偏好。虽然decltype可能在某些情况下有用但对于目前的需求仍然更倾向于使用C语言的子集。对于如何准确获取类型信息提出了一个假设的做法可能通过decltype获取控制器数组的大小但也承认这部分实现可能还存在一些未知的问题决定将其作为读者的练习留待解决。 问为什么你计划使用 OpenGL 或 DirectX 进行硬件加速实现这一点需要了解实际的 GPU 架构吗 在讨论为何选择使用OpenGL或DirectX时指出这两个是唯一能够有效访问3D硬件的API。现代计算机的CPU无法高效地进行图形渲染因此必须使用GPU来渲染游戏。虽然自己编写渲染器作为教育项目但最终不会将其作为游戏的主要渲染方式因为CPU渲染无法与GPU渲染的速度相比。 问你怎么看待 Khronos 的 Vulkan 对于Vulkan的看法目前尚未收到其规格说明因此无法做出具体评价。理想情况下希望硬件接口尽可能简化理想的状态是通过环形缓冲区与硬件直接交互而不需要驱动程序。如果Vulkan比现代OpenGL更接近这一目标那么它会是一个积极的进展。具体好处取决于Vulkan的设计质量如果设计得当将是一个显著的提升如果设计不理想则可能仍然是一个改进但不那么显著。 问当你知道如何编程但没有艺术技能时做游戏的最佳方式是什么找个艺术家来为你做吗这是我的软肋但我想自己做个游戏 如果有编程能力但缺乏艺术技能最好的方法是雇佣一位艺术家来完成视觉设计。但如果预算不足或者没有艺术技能可以考虑制作程序生成的游戏。很多成功的程序员都通过简单的艺术风格获得了受欢迎的游戏。可以尝试制作3D游戏利用光照来弥补艺术设计的不足或者通过简化图形定义来减少对复杂艺术内容的需求。 例如可以通过几何形状来创建游戏视觉或者借用现有的视觉设计比如《迷你地铁》这款游戏它的视觉设计非常简洁主要是基于地铁线路图。因此即使没有高端的艺术制作能力也可以通过借鉴已有的简单设计来构建游戏避免被艺术内容所限制。总之如果无法承担艺术制作最好定义一个能够不依赖复杂艺术而依然能吸引玩家的游戏设计理念。