等距碰撞检测

我在尝试检测两个等距图块的冲突时遇到了一些问题。

我尝试在图块上的每个点之间绘制线，然后检查线截距，但是这行不通（可能是由于公式错误）

经过一段时间的研究，我相信我正在考虑很多，而且必须有一种更简单的方法。

我不是在寻找代码，只是一些建议以最佳方式实现重叠检测

我会直截了当地说，我不知道如何解决您在问题中描述的问题（等分形矩形之间的冲突检测），但是我可以告诉您过去其他人如何解决它：

在其他游戏中完成的方式是将游戏世界与屏幕世界分开。当您刚开始时，通常会想像它们是同一件事，但这会导致出现您所描述的问题。

一般的想法是，游戏世界完全存储在内存中，在幕后，仅是数字，引用和逻辑。您以等轴测图绘制游戏世界的事实无关紧要。您的游戏世界不应该具有等距或正方形的概念，即使屏幕以3D绘制也是如此。当您将游戏世界绘制到屏幕（又称屏幕世界）时，所有这些工作都会得到照顾。应该以对游戏有意义的最简单方式来存储和维护游戏世界，在等距游戏中，您通常完全忽略它是iso的事实，而是像使用轴对齐网格一样存储位置。大部分游戏都会有方法在两个世界之间转换的坐标，我叫雷ScreenToWorld(x, y)和WorldToScreen(x, y)。转换通常是通过Matrix数学完成的，但可以通过其他方式实现。使用鼠标时将使用ScreenToWorld，绘制时将使用WorldToScreen。

拆分游戏世界和屏幕世界有几个好处。优势之一是碰撞检测和移动都发生在游戏世界中，因此通常很简单，因为您不需要处理倾斜的网格，不正确的坐标或屏幕所在的位置等。 ，您将要处理与轴对齐的矩形和正方形。更新游戏世界后，您可以在屏幕上用关键字：representation绘制游戏世界的表示形式。乍一看似乎违反直觉，但您的屏幕仅代表游戏世界中正在发生的事情。这使得专用服务器和类似终端的客户端成为可能。

FreeCiv实际上是所有这些方面的一个很好的例子。您可以查看与以下任何一个相同的确切世界：正方形的北/南网格，等轴测图，甚至是十六进制。您运行的每个游戏都有一个专用的服务器在后台运行，即使对于单人游戏也是如此，因此客户端也只是一个显示端口，仅此而已。

长话短说：将游戏世界和逻辑与屏幕世界分开，简化了游戏逻辑，减少了游戏与显示的耦合，进而使“ iso”图块之间的碰撞检测更易于处理和可视化。

约翰的回答是正确的，但我将尝试以另一种方式解释它：

没有等距碰撞检测。

碰撞检测并不关心您的投影矩阵/变换的外观。如果完全渲染物体，则碰撞检测无关紧要（毕竟，屏幕外的对象仍会碰撞，对吗？）

这是一个更具哲学意义的问题：当没人在那儿时，落在森林中的一棵树是否仍然与地面碰撞？

传统观点会说：是的。怎么看都没关系。事物在世界空间而非视图空间中发生碰撞。

您可以尝试分配一个像素数组，该像素数组构成每个像素的每个getRGB（）值的位图。不要将这些值与if语句进行比较，因为图块的边界是一个独立的颜色值，而不是图块所代表的颜色值（水，沙，草）。用于基本的等距网格。或者，您可以拥有地图本身的两层。一层包含类似于绿色屏幕的图层，绘制碰撞对象的每个代表的轮廓，另一层包含地图本身。

您无需组成地图层每个像素的位图数组，而是要计算一组颜色，这些颜色表示当对象碰撞/相交于保持颜色值的边界时其具有的效果。您希望值减小值或对象移动的速度增加。每个移动的对象只是存储在不同位置的内存的副本。

我将研究像素完美碰撞和对位图数组的理解。每个矩形都是一个包含复制数据类型（如压印内存）的边界，每个事件都根据对象在位置或向量中的渲染位置触发。屏幕上的每个点都在2D平面上，只是阴影的深度提供了一种幻觉，即对象将自身表示为3D。倾斜的形状变换使人感觉到物体处于一定角度。有一个中心点，摄像机可以看到它，一切都围绕着该中心点进行，该中心点的大小逐渐减小或越来越接近。