Verständnisfrage zu Kollisionsabfrage in P&C- Adventures. (2D)
-
Hallo,
ich habe einige allgemeine Verständnisfragen zu Kollisionserkennung in zweidimensionalen Point & Click - Adventures (2D mit perspektivischer Darstellung).
Um nicht lange um den heißen Brei herumreden zu müssen, hier eine einfache Skizze:
http://img141.imageshack.us/img141/8403/abcg.pngHellblau = Bereich in dem die Figur herumlaufen darf
Orange (Rahmen) = Rectangle der Sprites
Rot = Bereich der einzelnen Objekte/Figuren, der auf Kollision getestet werden soll.Nun zu meiner Frage. Wie wird in solchen p&c Adventures eine Kollision ermittelt? Wie man bei der Skizze erkennen kann, ist der rote Bereich kein Rechteck, sodass eine bounding box hierbei schon mal nicht in Frage kommt. Das ganze Sprite (orange) als bounding box zu nehmen entfällt auch, sonst sieht es nach Quatsch aus.
- Wie bestimme ich nun am elegantesten (und am besten mit nicht viel Rechenzeit) die Kollisionserkennung zwischen den ROT markierten FLächen?
1.1) Zu jedem Sprite eine extra Grafik anlegen, in der markiert ist wird, welche Bereiche der Originalgrafik auf Kollision getestet werden soll (pixelgenaue Kollisionstests).
oder
1.2) Eckpunkte der parallelogramm-förmigen (roten) Grundflächen speichern.
Linien, die aus je zwei Eckpunkten gebildet werden, mit Linien des Kollisionsobjekts auf Überschenidung testen?1.3) sonstige Wege?
Irgendwie erscheinen die Lösungswege bei 1.1) und 1.2) umständlich und rechenintensiv. Gibt es da keine einfacheren Wege?
Wie macht man das in professionellen P&C Adventures? Und wie legt man dort die (roten) Grundflächen fest? Per Editor?
MfG, Schneewittchen
- Wie bestimme ich nun am elegantesten (und am besten mit nicht viel Rechenzeit) die Kollisionserkennung zwischen den ROT markierten FLächen?
-
wie auch immer du das implementieren willst - auf die rechenzeit brauchst du bei nem p&c mit sicherheit nicht zu achten.
btw einfach rectangles auf überschneidung prüfen dürfte um einiges schneller sein als geraden zu schneiden.
-
TravisG schrieb:
wie auch immer du das implementieren willst - auf die rechenzeit brauchst du bei nem p&c mit sicherheit nicht zu achten.
btw einfach rectangles auf überschneidung prüfen dürfte um einiges schneller sein als geraden zu schneiden.
Und wie stellst du dir das vor? Grundfläche (rot) als Rechteck definieren kommt nicht in Frage, da es sonst scheiße aussieht und sich genau so spielt
Oder meinst du, dass man die trapezförmige Grundfläche mit ganz vielen kleinen Rechtecken füllen soll um eine Trapezförmige Annäherung zu schaffen?
-
Schneewittchen schrieb:
TravisG schrieb:
wie auch immer du das implementieren willst - auf die rechenzeit brauchst du bei nem p&c mit sicherheit nicht zu achten.
btw einfach rectangles auf überschneidung prüfen dürfte um einiges schneller sein als geraden zu schneiden.
Und wie stellst du dir das vor? Grundfläche (rot) als Rechteck definieren kommt nicht in Frage, da es sonst scheiße aussieht und sich genau so spielt
Oder meinst du, dass man die trapezförmige Grundfläche mit ganz vielen kleinen Rechtecken füllen soll um eine Trapezförmige Annäherung zu schaffen?
achso, ich hab mich an der skizze orientiert und dachte das sind rechtecke. das mit den parallelogrammen hab ich wohl unterbewusst einfach ignoriert. wenn du durch kleine rechtecke ne näherung schaffen willst, hast du i.d.R (es sei denn du machst es ganz grob, z.b. 2 rechtecke pro parallelogramm) um einiges mehr rechenzeit verdampft als du für geraden schneiden bräuchtest.
in dem fall sollte geraden schneiden kein problem sein.
-
normalerweise wuerde man einfach einzeichnen an welcher stelle z.b. die die mitte der unteren kante vom player-sprite positioniert werden darf.
kollisionstesten ist dann ein auslesen aus dem bild.
du musst ja auch "kollisionen" bei der wegfindung pruefen, das sollte also nicht zu langsam gemacht werden.
-
Oder du machst ein wenig 3-D-Mathematik. Du Hast einfach X-Y-Z Koordinaten (wobei wahrscheinlich deine Y-Koordinate immer 0 sein wird, da sich der Spieler ja immer auf dem Boden befindet). Dann sind die Kollisionen in der X/Z Ebene nur Kollisionen von Rechecken. Dann musst du das ganze nur noch mit einer parallel Projektion in Bildschirmkoordinaten umrechnen.
Y Z ^ ^ / | / | / |/ |---------> X
