Breakout Kollision mit Stein und dann?



  • Hallo

    Ich schreibe gerade ein kleines Breakout und soweit funktioniert es auch, jedoch habe ich ein kleines Problem mit der Kollision mit einem Stein.

    Also die Kollision von einem Ball mit einem Stein abzufangen funktioniert, ich muss nun jedoch den speedY umkehren wenn der Ball von unten oder oben auf den Stein trifft, jedoch den speedX umkehren wenn er von rechts oder links den Stein berührt.

    Ich benutze folgendes als Lösung, denke aber das dies nicht die beste Idee ist:

    if (ballSprite.getX() + ballSprite.getWidth() == brick.getX() ||
        ballSprite.getX() == brick.getX() + brick.getWidth())
          // Kehre XSpeed um
    else
          // Kehre YSpeed um
    

    Hat wer einen Lösungsvorschlag?

    Gruss
    Samyboy



  • Hi,

    Also zunächst Mal nutzt du eine rechteckige Kollisionsabfrage, obwohl der Ball rund ist, oder? Evtl. approximiert das dein Ergebnis zwar, allerdings ist eine "Kreis zu Rechteck"-Kollisionsabfrage auch nicht sonderlich schwierig.

    Dann testest Du, ob Ball + Breite == Brick-Position ist. Wenn Du die linke Wand nur um einen Pixel verfehlst, zählt das also nicht mehr als Kollision. Damit setzt Du also voraus, dass Position, x-Bewegung des Balls sowie Breiten von Brick und Ball immer im selben Raster liegen... Das ist ziemlich nervig, wenn Du verschiedene Ballbeschleunigungen oder framebasierte Bewegungen (das solltest Du sowieso machen, da das Spiel auf verschiedenen Computern sonst unterschiedlich schnell läuft) unterstützen möchtest.

    Normalerweise nutzt man für rechteckige Kollisionsabfrage etwa Folgendes:

    x1 + w1 > x2 && x1 < x2 || x1 == x2 || x1 < x2 + w2 && x1 > x2
    

    und das gleiche für y und h.

    Falls du pro Frame eine Bewegung machst und diese zeitabhängig ist, kann es Sprünge geben. Da kann man optimieren, indem man Linien zeichnet (von Start zu Ziel) und diese in z.B. 10 Bewegungen pro Frame aufteilt (z.B. unter Festlegung einer Minimalbewegungs-Konstante pro Bewegung).



  • Eisflamme schrieb:

    Hi,

    Also zunächst Mal nutzt du eine rechteckige Kollisionsabfrage, obwohl der Ball rund ist, oder? Evtl. approximiert das dein Ergebnis zwar, allerdings ist eine "Kreis zu Rechteck"-Kollisionsabfrage auch nicht sonderlich schwierig.

    Dann testest Du, ob Ball + Breite == Brick-Position ist. Wenn Du die linke Wand nur um einen Pixel verfehlst, zählt das also nicht mehr als Kollision. Damit setzt Du also voraus, dass Position, x-Bewegung des Balls sowie Breiten von Brick und Ball immer im selben Raster liegen... Das ist ziemlich nervig, wenn Du verschiedene Ballbeschleunigungen oder framebasierte Bewegungen (das solltest Du sowieso machen, da das Spiel auf verschiedenen Computern sonst unterschiedlich schnell läuft) unterstützen möchtest.

    Normalerweise nutzt man für rechteckige Kollisionsabfrage etwa Folgendes:

    x1 + w1 > x2 && x1 < x2 || x1 == x2 || x1 < x2 + w2 && x1 > x2
    

    und das gleiche für y und h.

    Falls du pro Frame eine Bewegung machst und diese zeitabhängig ist, kann es Sprünge geben. Da kann man optimieren, indem man Linien zeichnet (von Start zu Ziel) und diese in z.B. 10 Bewegungen pro Frame aufteilt (z.B. unter Festlegung einer Minimalbewegungs-Konstante pro Bewegung).

    Hallo

    Danke für die Erläuterung, es geht mir jedoch nicht um die Kollision Erkennung, die klappt super, es geht mir darum wie der Ball dann abprallt nachdem die Kollision stattgefunden hat, darum versuche ich herauszufinden ob der Ball links, rechts oder oben, unten vom Brick ist, aber das scheint mir wie du gesagt hast nicht möglich mit meiner Funktion, daher suche ich hier Hilfe...

    Hope that makes sense...



  • Hi,

    Verstehe. Also wenn Du keine Schrägen oder schräge Abprallwinkel hast, reicht dein Ansatz natürlich aus. Dennoch musst du in diesem Raster bleiben, was es eben schwierig macht deine Kollisionsabfrage zu benutzen. Ich denke, Du wirst irgendwann darauf stoßen, dass Du die eh ändern musst. Je nachdem, wo der Ball auf das Schlagbrett eintritt, fliegt die Kugel ja auch anders wieder weg, sonst wäre das Spiel langweilig.

    Ansonsten ist an deinem Ansatz nichts verkehrt. Je nach Seite des Aufpralls, negierst Du eben die entsprechende Koordinate. Wenn Du nur an Achsen angeordnete Objekte hast (also keine Schrägen), reicht das m.M.n. vollkommen aus.


Log in to reply