Izometryczne wykrywanie kolizji

Mam problemy z próbą wykrycia kolizji dwóch płytek izometrycznych.

Próbowałem wykreślić linie między każdym punktem na kafelku, a następnie sprawdzić, czy nie przechwytuje linii, ale to nie działało (prawdopodobnie z powodu nieprawidłowej formuły)

Po dłuższym zastanowieniu się nad tym, wydaje mi się, że zastanawiam się nad tym i musi istnieć łatwiejszy sposób.

Nie szukam kodu, tylko kilka porad, jak najlepiej wykryć nakładanie się

Zaraz wyjdę i powiem, że nie wiem, jak rozwiązać problem opisany w pytaniu (wykrywanie kolizji między prostokątami w kształcie kafelków iso), ale mogę powiedzieć, jak inni rozwiązali go w przeszłości :

W innych grach sposób polega na oddzieleniu świata gry od świata ekranu . Kiedy zaczynasz, często wyobrażasz sobie, że są tym samym, ale prowadzi to do problemów takich jak ten, który opisujesz.

Ogólna idea jest taka, że świat gry jest przechowywany całkowicie w pamięci, za kulisami, to tylko liczby, referencje i logika. Fakt, że rysujesz świat gry w rzucie izometrycznym, nie ma znaczenia. Twój świat gry nie powinien mieć koncepcji izometrycznej, kwadratowej, a nawet jeśli ekran jest rysowany jako 3D. Wszystko to załatwia się, gdy narysujesz świat gry na ekranie (inaczej świat ekranu ). Świat gry powinien być przechowywany i utrzymywany w najprostszy sposób, który ma sens w grze, w grach izometrycznych zazwyczaj całkowicie ignorujesz fakt, że jest to iso i zamiast tego przechowujesz pozycje, jakbyś używał siatki wyrównanej do osi. Większość gier będzie miała metody przekształcania współrzędnych między dwoma światami, nazywam mój ScreenToWorld(x, y)iWorldToScreen(x, y). Konwersji często dokonuje się za pomocą matematyki Matrix, ale można to osiągnąć innymi sposobami. Będziesz używać ScreenToWorld podczas używania myszy, a WorldToScreen podczas rysowania.

Podział świata gry i świata ekranu ma kilka zalet . Jedną z zalet jest to, że wykrywanie kolizji i ruch zdarzają się w świecie gry, a zatem zazwyczaj jest to bardzo proste, ponieważ nie masz do czynienia z nachyloną siatką, skośnymi współrzędnymi lub miejscem, w którym znajduje się ekran itp. W twoim przypadku , miałbyś do czynienia z prostokątami i kwadratami wyrównanymi do osi. Po zaktualizowaniu świata gry rysujesz na ekranie reprezentację świata gry, słowo kluczowe: reprezentacja. Na początku może się to wydawać sprzeczne z intuicją, ale Twój ekran jest jedynie reprezentacją tego, co dzieje się w świecie gry. Dzięki temu możliwe są takie serwery dedykowane, jak klienci podobni do terminali.

FreeCiv jest w rzeczywistości doskonałym przykładem tych wszystkich rzeczy. Możesz zobaczyć dokładnie ten sam świat, co dowolny z: kwadratową siatkę północ / południe, izometryczny, a nawet hex. Każda uruchomiona gra ma dedykowany serwer działający w tle, nawet w przypadku gier dla jednego gracza, dlatego klient jest tylko portem wyświetlania, niczym więcej.

Krótko mówiąc: Oddzielenie świata gry i logiki od świata ekranu upraszcza logikę gry, zmniejsza sprzężenie wyświetlania <-> i z kolei ułatwia wykrywanie kolizji między płytkami „iso” i wizualizację.

Odpowiedź Johna jest słuszna, ale postaram się wyjaśnić to w inny sposób:

Nie ma izometrycznego wykrywania kolizji.

Wykrywanie kolizji nie ma znaczenia, jak wygląda twoja matryca / transformacja projekcyjna. Wykrywanie kolizji nie powinno mieć znaczenia, jeśli w ogóle renderujesz rzeczy (w końcu obiekty, które są poza ekranem, mogą nadal kolidować, prawda?)

Jest to bardziej filozoficzne pytanie: czy drzewo spadające w lesie nadal zderza się z ziemią, gdy nikogo tam nie ma?

Konwencjonalna mądrość powiedziałaby: tak. Nie ważne jak na to patrzysz. Rzeczy zderzają się w przestrzeni świata, a nie w przestrzeni widzenia.

Możesz spróbować przydzielić tablicę pikseli tworzących mapę bitową każdej wartości getRGB () każdego pojedynczego piksela. Następnie porównaj wartości z instrukcją if, ponieważ obramowania kafelka to osobna wartość koloru niż wartość reprezentowana przez kafelek (woda, piasek, trawa). To dla podstawowej siatki izometrycznej. Lub możesz mieć dwie warstwy samej mapy. Jedna warstwa zawiera coś w rodzaju zielonego ekranu rysującego kontur każdego przedstawiciela zderzającego się obiektu, a druga warstwa będzie samą mapą.

Nie tworzysz tablicy bitmapowej każdego piksela warstwy mapy, zamiast tego chcesz obliczyć zestaw kolorów reprezentujących efekty, jakie ma, gdy obiekt zderza się / przecina granicę utrzymywania wartości koloru. Albo chcesz, aby wartości spadały lub zwiększały prędkość, z jaką porusza się obiekt. Każdy obiekt, który się porusza, to po prostu duplikat pamięci przechowywanej w innym miejscu.

Chciałbym przyjrzeć się idealnej kolizji pikseli i zrozumieniu tablic bitmapowych. Każdy prostokąt ma granice zawierające replikację danych, takich jak odcisk pamięci, każde zdarzenie jest wyzwalane w zależności od tego, gdzie obiekt jest renderowany w lokalizacji lub wektorze. Każdy punkt na ekranie jest na płaszczyźnie 2D tylko tyle, że głębia cienia zapewnia złudzenie, że obiekt przedstawia się jako 3D. Transformacja kształtów w pochyleniu daje poczucie, że obiekt znajduje się pod kątem. Jest centralny punkt, w którym kamera pokazuje, że wszystko jest przenoszone wokół tego punktu centralnego, oddalając się od niego, zmniejszając rozmiar lub zbliżając się do niego, zwiększając rozmiar.