panel "intersect"

Im Zuge der 2d-Verbesserung schlage ich einen Befehl, ähnlich dem im (damals Macromedia) Director vor.

"intersect".

Wenn sich 2 Panels überlagern, und zwar nur im Falle der sichtbaren, nicht im alpha-Kanal durch schwarze ausgenommenen,
Pixel-Bereiche - dann sollte ein Rückgabewert "result=1" aus einer Funktion resultieren.

Damit könnte man herrliche Adventure-Animationen und Kollisions-Abragen machen.

Das wäre super, wenn es das bald gäbe. Ich habe vor Ewigkeiten einmal ActionScript in Flash programmiert.

Nebenbei, gibt es keine Möglichkeit in Game Studio eine 2d-Kollisionsabfrage zu implementieren?

Beide Anfragen sind zwar sinnvoll, können aber von euch selbst geschrieben werden. intersect bekommt 2 Panels zugeschoben und vergeleicht erst ob sich die Beiden überlappen (p1.x < p2.x, p1.x+p1.with > p2.x+p2.with, etc.) und dann Pixel für Pixel alle Werte (alpha picking). Mit dem gleichen Prinzip könnte eine Funktion die ein Panel und einen Punkt nimmt implementiert werden.

Stimmt auch wieder.

Danke für deine Antwort.

ist auch kaum rechenaufwand. zwei panels mit 100x200 pixeln bedeuten 20 000² = 400 000 000 alphakanalvergleiche, wenn sie genau übereinanderliegen, im mittel also die hälfte. unoptimiert ist das kaum machbar. hat jemand eine implementationsidee? vielleicht eine vorberechnete polygonale bounding-fläche für panels?

Also den Vergleich über den Alphakanal zu machen ist grob fahrlässig da man erstens Perfomanceprobleme kriegt, wenn man das z.B. jeden Frame macht mit mehreren Panels und zweitens wirds frickelig, wenn du das Panel skalierst und/oder rotierst.

Eine einfache Möglichkeit bietet sich an zu testen ob sich zwei triangles überlappen. Dann kannst du nämlich die beiden notwendigen triangles der gedrehten und skalierten Boundingbox eines Panels nehmen, die eines anderen Panels nehmen und schnell vergleichen.

Für genauere Kollisionsshapes bieten sich nun folgende Alternativen an:

1.) Ein konvexes polygonales shape
2.) Ein konkaves polygonales shape
3.) Eine pixelgenaue Beschreibung des Kantenzugs des Objektes

Zu 1 und 2: dies ist nur eine Annäherung aber deshalb auch schnell. Das konkave shape muss eventuell trianguliert werden. In beiden Fällen sollte das Shape extern gespecihert und zur Laufzeit geladen werden. Es gibt diverse Algorithmen (papers, ausformuliert, demos, sourcecode), die solche Kollisionen berechnen. Wahrscheinlich ist 1. schneller und einfacher zu realisieren.

Zu 3: Man kann pixelgenau Kantenzüge relativ kostengünstig mithilfe des chain codes speichern, wobei man die Alternativen Manhattan Distanz und Euklid hat. Euklid erlaubt auch diagonale Züge, speichert also wesentlich weniger Daten und erlaubt eine genauere Approximation des Kantenzuges. Man könnte in ein Array dann die chaincodes (eventuell abgebildet, bedingt durch Rotation/Skalierung/Projektion) eintragen. Sobald eine Kollision stattfindet, wird dann ein solcher Pixel mehrfach belegt und schon kannste prima Events triggern.

(Binäre-)Alphamasken zu durchlaufen ist echt schrecklich, da die Betrachtung aller Pixel bei zunehmender Fläche wächst - und zwar quadratisch! Wäh...

Zusätzlich dazu möchte ich anmerken, dass bei der Betrachtung von Kollisionen man evtl. auch darauf achten muss, ob sich ein Objekt bewegt und zwar in diesem und letztem Frame eventuell keine Kollision feuert, "aber auf dem Weg" ein gefeuert hätte (Beispiel: Pistolenkugel durchstößt Wand, weil sich die Kugel zu schnell bewegt).

@HeelX,

das würde auf jedem Fall funktionieren. Am sinnvollsten wäre es dann, diese Daten direkt beim erstellen eines Panels zu berechnen, und dann nur noch bei Veränderungen zu speichern. Die Rotation hatte mir auch schon Kopfzerbrechen bereitet, da ja alle Punkte per Rotationsformel rotiert werden müssten.

Ein Alphavergleich ist auf jedem Fall zu Zeitaufwändig, aber bringt auch den Vorteil mit sich, das man zum Beispiel bei einem Viereck mit einem Kreisausschnitt in der Mitte genaue Kollisionsabfragen machen kann. soll heisen: wenn mein Objekt in der Mitte des Kreises in meinem Viereck ist, soll keine Kollision stattfinden.

Alles in allem spricht es meiner Meinung nach dafür, Panels als Vectorengrafiken zu speichern. Man kann ja optional für Bilder anhand einer Alphawertanalyse oder per "Transparenter Farbe" eine BoundingBox berechnen.

gruß
steev

Ich schaue mal, was ich da implementieren kann. Die Intersection gedrehter Panels ist einfach, aber ein Alphavergleich ist sehr zeitaufwendig.

Naja geht, du kennst den Origin des Panels, seine Skalierung und seine Maße, sowie seine Rotation. Du kannst die 4 Eckpunkte durch die Vektorbefehle recht einfach ausrechnen.

es muss nicht jedes pixel einzeln durchlaufen werden. & << >> sind bei sowas deine freunde!