2D Kollisionsabfrage---Wann ?
-
jotzi schrieb:
So habe ich bis jetzt gearbeitet. Der Nachteil, den ich sehe, ist der, daß wenn ich vor einer Wand stehe und auf sie zugehe, diese "Wackelfigur" habe, die immer zurückgesetzt wird. Gibt es in kommerziellen Spielen zwar auch, ist aber leider imo hässlich.
Na eigentlich dürfest du dieses Wackeln nicht kriegen: Du bewegst die Figur, prüfst dann die Kollision, setzt die Figur gegebenenfalls zurück, und renderst dann alles.
-
Rechne dir die neue Position aus, dann guck ob was kollidiert. Wenn was kollidiert geh zurück auf die alte Position, und guck wie weit genau (Pixel für Pixel) du gehen kannst ohne dass was kollidiert.
Dadurch bleibst du nicht 3px vor der Wand stehen und "wackelst" auch nicht.
-
jotzi schrieb:
So habe ich bis jetzt gearbeitet. Der Nachteil, den ich sehe, ist der, daß wenn ich vor einer Wand stehe und auf sie zugehe, diese "Wackelfigur" habe, die immer zurückgesetzt wird.
Die bekommst du nur, wenn du dich zuerst nach vorne bewegst, dann renderst, und erst _zuletzt_ zurücksetzt. ich würde zurücksetzen immer sofort nach dem update der position machen und das updaten/collision-detecting ganz vom rendering trennen, dann kann sowas gar nicht erst passieren.
-
is doch egtl pillepalle. wenn man zuerst berechnet ob man kollidiert, kann man doch anschließend auch gleich berechnen wie weits noch ist, damit alles "bündig" sitzt und das objekt dementsprechend bewegen.
-
Es läuft.
Vielen Dank...Wenn du aber die Figur schön bündig zur Wand setzt, dass kein Abstand mehr besteht (durch Berechnung)
Brauch ich nicht "berechnen" lassen. Eine Schleife prüft die Kollision und setzt solange genau ein pixel zurück bis keine Kollision mehr stattfindet.
Ok, den Abstand zu berechnen wäre eleganter, aber ich werde ja nie mehr als 3-5 (10?
Schleifendurchläufe brauchen
-
TravisG schrieb:
is doch egtl pillepalle. wenn man zuerst berechnet ob man kollidiert, kann man doch anschließend auch gleich berechnen wie weits noch ist, damit alles "bündig" sitzt und das objekt dementsprechend bewegen.
Meistens, vor allem bei einfachen Kollisionsabfragen wie Rechteckskollisionen ist das sowieso zu empfehlen. Da muss man zwei Variablen weniger speichern. Und die Berechnung der Position braucht eh keine Performance. Zudem ist der Effekt auch sauberer und optisch schöner.
Wenn man jedoch kompliziertere Abfragen hat - besonders wenn die Abfrage selber zwar noch einfach geht, aber die Reaktion darauf ziemlich mühsam ist - kann eine Rücksetzung auf vorherige Koordinaten trotzdem in Betracht gezogen werden. Dennoch ist dieser Lösungsansatz eher unschön und sollte, wenn möglich, durch eine berechnete neue Position ersetzt werden.
jotzi schrieb:
Brauch ich nicht "berechnen" lassen. Eine Schleife prüft die Kollision und setzt solange genau ein pixel zurück bis keine Kollision mehr stattfindet.
Ok, den Abstand zu berechnen wäre eleganter, aber ich werde ja nie mehr als 3-5 (10?
Schleifendurchläufe brauchenWürde ich aber trotzdem empfehlen, auch wenn die Performance nicht ausschlaggebend ist. Damit bist du flexibler und kannst die Kollisionsreaktion auch genauer anpassen. Vor allem wenn du mit Float-Koordinaten rechnest, ist eine Schleife definitiv fehl am Platz. Und so schwierig ist das ja wirklich nicht zu implementieren, oder?
-
Und so schwierig ist das ja wirklich nicht zu implementieren, oder?
Vor einem halben Jahr war es das
Aber meine Natur geht leider zu oft den Weg des geringsten Widerstands.Aber du hast völlig Recht. Da ich nach der Test-Frickelei jetzt sowieso die ein oder andere Methode umschreiben werde, kann eine "Radikal-Kur" schon alleine für Übungszwecke nur von Nutzen sein.
-
jotzi schrieb:
Vor einem halben Jahr war es das
Aber meine Natur geht leider zu oft den Weg des geringsten Widerstands.Aber du hast völlig Recht. Da ich nach der Test-Frickelei jetzt sowieso die ein oder andere Methode umschreiben werde, kann eine "Radikal-Kur" schon alleine für Übungszwecke nur von Nutzen sein.
Das kenne ich nur zu gut
Ich hab einmal ein Jump'n'Run geschrieben, und will das, wenn ich einmal viel Zeit habe, von Grund auf neu programmieren und verbessern. Zum Teil sind Kollisionsabfragen (bei schrägen 45°-Hängen) solche Frickeleien mit 7 verschiedenen Fällen und trotzdem total verbuggt, sodass sich nur eine komplette Neuimplementierung lohnt. Und reden wir jetzt nicht über Speicheranforderung und sauberes Aufräumen und solche Sachen
Naja, man lernt eben immer dazu
-
Am meisten frustriert mich, daß die Lösung eines Problems meist 2-3 völlig unerwartet Neue mit sich zieht...
Man reckt die Faust in die Höhe, schreit "Hurra", drückt auf "Run" und jetzt wo endlich wirklich, 100%ig, jetzt bestimmt endlich und sowieso der Fehler behoben wurde, klappt es leider immer noch nicht
-
Mit der Zeit gewöhnt man sich eben daran und ist dann nicht mehr so schnell euphorisch, dafür umso mehr, falls etwas mal wirklich klappt
