PureBoard

Hallo,
ich versuche nun seit Tagen eine JaR Engine zu schreiben. Ich hab mir schon mehrere System aufgebaut allerdings hab ich ständig Probleme mit der Kollisionserkennung.
Daher mal eine einfache Frage die mir schon sehr helfen würde: Gibt es eine Möglichkeit, wenn man mit SpritePixelCollision() eine Kollision abfragt, festzustellen wo die Kollision stattfindet? Also zb. am unteren oder an der linken oder rechten Seite des Sprites?
LG

Also mir wäre keine direkte möglichkeit bekannt, allerdings könntest du ja rein theoretisch dein sprite auf 4 einzelteile aufteilen (sprich: oben, unten, links, rechts) und dort jeweils die kollision abprüfen lassen.
In diesem Fall kannste dann auch auf die SpritePixelCollision() verzichten und das ganze rechnerisch machen - zumindest wenn es dir wirklich nur drauf ankommt herauszufinden an welcher seite die kollision stattfindet.

Iss nur n kleiner spontaner denkansatz meinerseits - kann sein dass nun n echter profi ankommt und den völlig in der luft zerfetzt, aber vllt. hilfts dir ja dennoch weiter


Mfg
RaVeN

Naja im Normalfall weißt Du ja, wo Deine Figuren sind. Ich geh jetzt einfach mal davon aus, Du programmierst einen Mario-Clone, und willst, daß die Gegner sterben, wenn der Spieler draufspringt; andernfalls soll der Spieler Energie verlieren bzw. sterben.

Jetzt kannst Du im Falle einer Kollision ja einfach schauen, ob der Spieler sich y-mäßig z.B. um eine bestimmte Anzahl Pixel ÜBER dem Gegner befindet. Wenn ja, weißt Du, daß der Gegner den kürzeren zieht und nicht der Spieler

Aber davon abgesehen würde ich auf SpritePixelCollision ebenfalls verzichten - das ist nur dann sinnvoll, wenn Deine Sprites es wirklich nötig haben (von ihrer Form her gesehen). Solang das Sprite aber eine gewöhnliche Figur ist, ist das nicht nötig. Da testest Du einfach die Positionen gegeneinander, also z.B. so:
Die Toleranz hängt von Deinen Figuren ab, in den meisten Fällen bewährt sich hier jeweils die Hälfte der Figur-Breite bzw. Hälfte der Figur-Höhe.

Somit hast Du jede Kollision schonmal erkannt. Wenn Du es tatsächlich GENAU haben willst, solltest Du es dennoch so machen, wie beschrieben, und DANN im Falle der Kollision noch nachträglich SpritePixelCollision() anwenden - in allen anderen Fällen brauchst Du das aber schon gar nicht mehr aufrufen (logisch). Denn wenn Du alles mit SpritePixelCollision überprüfst, könnte das recht langsam werden.

Egal wie Du es handhabst, die Prüfung, wer von beiden nun den anderen tötet, machst Du dann auch erst im (endgültigen) Falle einer Kollision. Am besten übergibst Du an eine weitere Procedure die beiden Figuren, die kollidieren, und dort wird dann weiter ausgewertet, wie sich das nun verhalten soll.

> und DANN im Falle der Kollision noch nachträglich SpritePixelCollision() anwenden

das ist nicht nötig.
afaik prüft SpritePixelCollision zuerst ob die sprites überhaupt übereinanderliegen,
bevor es anfängt die pixel durchzuhecheln.

aber trotzdem:
wie die Kollegen schon sagten, SpritePixelCollision ist ein irrsinniger Performance-fresser,
und für die meisten belange eigentlich unnötig.

am besten stellst du dich von vornherein auf eine koordinaten-verrechnung um.
da hättest du auch den vorteil, dass du auf teilbereiche des sprites testen kannst.

die berechnung, wie die spielfigur auf dem boden läuft ist noch einfacher:
du testest einfach nur, was für eine tile sich hinter der figur
und was für eine sich unter ihren füßen befindet.

ich nehme mal an du hast probleme das hinzubekommen dass man von ner wand/decke/boden unterschiedlich geblockt wird?

ich habe bei meinem versuch sowas zu baun einfach getestet ob der charakter rechts/links läuft und so fallunterscheidungen gemacht

also wenn er rechts läuft und gegen die wand rennt wird er nach links verschoben

ich hoffe das hilft dir

Hallo,
danke erstmal für die ganzen Tipps. Der letzte Poster hatte recht, mein Problem war die unterschiedlichen Blocks zu unterscheiden.
Ich hab das Problem nun auch gelöst.
Ich hab meine Spieler Sprite in mehrere Punkte aufgeteilt und kann nun jede Region einzeln gezielt abfragen.
Im moment arbeite ich gerade an der Laufphysik. Na mal sehen, wie es weiter geht...