Détection de collision isométrique

J'ai des problèmes pour essayer de détecter la collision de deux tuiles isométriques.

J'ai essayé de tracer les lignes entre chaque point sur la tuile, puis de vérifier les interceptions de ligne, mais cela n'a pas fonctionné (probablement en raison d'une formule incorrecte)

Après avoir examiné cela pendant un certain temps aujourd'hui, je pense que j'y pense beaucoup et il doit y avoir un moyen plus facile.

Je ne cherche pas de code juste quelques conseils sur la meilleure façon de détecter les chevauchements

Je vais tout de suite dire que je ne sais pas comment résoudre le problème que vous avez décrit dans la question (détection de collision entre des rectangles en forme de tuile iso), mais je peux vous dire comment d'autres l'ont résolu dans le passé :

La façon dont cela se fait dans d'autres jeux consiste à séparer le monde du jeu du monde de l' écran . Lorsque vous commencez, il est courant d'imaginer qu'ils sont la même chose, mais cela conduit à des problèmes comme celui que vous décrivez.

L'idée générale est que le monde du jeu est entièrement stocké en mémoire, dans les coulisses, c'est juste des chiffres, des références et de la logique. Le fait que vous dessiniez le monde du jeu en isométrique est sans importance. Votre monde de jeu ne devrait pas avoir le concept d'isométrique ou de carré, ni même si l'écran est dessiné en 3D. Tout cela est pris en charge lorsque vous dessinez le monde du jeu à l'écran (alias le monde de l' écran ). Le monde du jeu doit être stocké et entretenu de la manière la plus simple qui soit logique pour le jeu, dans les jeux isométriques, vous ignorez complètement le fait qu'il est iso et stockez plutôt les positions comme si vous utilisiez une grille alignée sur l'axe. La plupart des jeux auront des méthodes pour convertir les coordonnées entre les deux mondes, j'appelle le mien ScreenToWorld(x, y)etWorldToScreen(x, y). La conversion est souvent effectuée avec Matrix Math, mais peut être réalisée par d'autres moyens. Vous utiliserez ScreenToWorld lorsque vous utilisez la souris et WorldToScreen lorsque vous dessinez.

Il y a plusieurs avantages à séparer le monde du jeu et le monde de l' écran . L'un des avantages est que la détection des collisions et les mouvements se produisent tous dans le monde du jeu, et sont donc généralement assez simples car vous n'avez pas affaire à une grille inclinée, à des coordonnées asymétriques, à l'emplacement de l'écran, etc. Dans votre cas , vous auriez affaire à des rectangles et des carrés alignés sur l'axe. Une fois le monde du jeu mis à jour, vous dessinez une représentation du monde du jeu à l'écran, mot-clé: représentation. Cela peut sembler contre-intuitif au premier abord, mais votre écran n'est qu'une représentation de ce qui se passe dans le monde du jeu. Cela rend possible des choses comme des serveurs dédiés et des clients de type terminal.

FreeCiv est en fait un excellent exemple de toutes ces choses. Vous pouvez voir le même monde exact que n'importe lequel: une grille carrée Nord / Sud, isométrique ou même hexadécimale. Chaque jeu que vous exécutez a un serveur dédié fonctionnant en arrière-plan, même pour les jeux solo, le client n'est donc qu'un port d'affichage, rien de plus.

Pour faire court: séparer le monde du jeu et la logique du monde de l'écran simplifie la logique du jeu, réduit le couplage d' affichage du jeu <-> et, à son tour, rend la détection de collision entre les tuiles "iso" plus facile à manipuler et à visualiser.

La réponse de John est tout à fait juste, mais je vais essayer de l'expliquer d'une manière différente:

Il n'y a PAS de détection de collision isométrique.

La détection de collision ne se soucie pas de l'apparence de votre matrice / transformation de projection. La détection de collision ne devrait pas avoir d'importance si vous restituez des choses (après tout, les objets qui sont hors de l'écran peuvent toujours entrer en collision, non?)

C'est une question plus philosophique: est-ce qu'un arbre qui tombe dans une forêt entre en collision avec le sol quand il n'y a personne là-bas?

La sagesse conventionnelle dirait: oui. Peu importe comment vous le regardez. Les choses entrent en collision dans l'espace-monde et non dans l'espace-vue.

Vous pouvez essayer d'allouer un tableau de pixels composant une image bitmap de chaque valeur getRGB () de chaque pixel individuel. Ensuite, comparez les valeurs avec une instruction if car les bordures de la tuile sont une valeur de couleur distincte de celle de ce que la tuile représente (eau, sable, herbe). Cela pour une grille isométrique de base. Ou vous pouvez avoir deux couches de la carte elle-même. Une couche contenant un peu comme un écran vert dessinant le contour de chaque représentant d'un objet entrant en collision et l'autre couche sera la carte elle-même.

Vous ne composez pas un tableau bitmap de chaque pixel de la couche de carte à la place, vous souhaitez calculer un ensemble de couleurs représentant les effets qu'il a lorsqu'un objet entre en collision / coupe la bordure de la valeur de couleur de maintien. Soit vous voulez que les valeurs diminuent ou augmentent la vitesse dans laquelle l'objet se déplace. Chaque objet qui se déplace n'est qu'un double de la mémoire stockée dans un endroit différent.

J'examinerais la collision parfaite de pixels et la compréhension des tableaux bitmap. Chaque rectangle est une limite de contenant des données de réplication sorte de mémoire imprimée comme chaque événement est déclenché en fonction de l'endroit où un objet est rendu dans un emplacement ou un vecteur. Chaque point de l'écran n'est sur un plan 2D que la profondeur de l'ombre donnant l'illusion que l'objet se représente lui-même en 3D. La transformation des formes en biais donne l'impression que l'objet est incliné. Il y a un point central où la caméra la présente. Tout est transporté autour de ce point central, s'éloignant de lui diminuant de taille ou se rapprochant de lui, augmentant de taille.