Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

19.05.2017, 19:28

Breakout: Kollision an Bricks berechnen

Hallo, ich möchte das Spiel Breakout programmieren bin dabei auch schon ziemlich weit. Nun möchte ich berechnen, von welcher Seite der Ball den jeweiligen Brick trifft, um dann seine Richtung zu ändern. Hatte dazu selbst keine Idee und habe deshalb gegoogled. Bin dann auf das hier gestoßen:

(Link)

Wenn die rote Strecke länger ist, dann ist das kleine Rechteck von links oder rechts gekommen, wenn die blaue Strecke länger ist, dann umgekehrt. Habe das nun implementiert, allerdings funktioniert es nicht gerade gut... Wäre toll, wenn ihr mal einen Blick drauf werfen könntet, habe die Methode nämlich nicht richtig verstanden :D

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
enum class Direction
{
    None = -1,
    Left,
    Right,
    Top,
    Bottom,
    Vertical,
    Horizontal
};

template <typename T>
Direction CollisionDirection(const sf::Rect<T> &mRect1, const sf::Rect<T> &mRect2, bool bDimensionsOnly = false)
{
    if(mRect1.intersects(mRect2))
    {
        T Xmin, Xmax, Ymin, Ymax = 0;

        sf::Vector2<T> mRect1Pos, mRect2Pos;

        mRect1Pos.x = mRect1.left + (mRect1.width / 2);
        mRect1Pos.y = mRect1.top + (mRect1.height / 2);

        mRect2Pos.x = mRect2.left + (mRect2.width / 2);
        mRect2Pos.y = mRect2.top + (mRect2.height / 2);

        T OverlapX, OverlapY = 0;

        if(mRect1.top > mRect2.top)
        {
            Ymin = mRect1.top;
        }
        else
        {
            Ymin = mRect2.top;
        }

        if(mRect1.top + mRect1.height < mRect2.top + mRect2.height)
        {
            Ymax = mRect1.top + mRect1.height;
        }
        else
        {
            Ymax = mRect2.top + mRect2.height;
        }

        if(mRect1.left > mRect2.left)
        {
            Xmin = mRect1.left;
        }
        else
        {
            Xmin = mRect2.left;
        }

        if(mRect1.left + mRect1.width < mRect2.left + mRect2.width)
        {
            Xmax = mRect1.left + mRect1.width;
        }
        else
        {
            Xmax = mRect2.left + mRect2.width;
        }

        OverlapY = Ymax - Ymin;
        OverlapX = Xmax - Xmin;

        if(OverlapY < OverlapX)
        {
            if(bDimensionsOnly)
                return Direction::Horizontal;
            if(mRect1Pos.y < mRect2Pos.y)
                return Direction::Bottom;
            else
                return Direction::Top;
        }
        if(OverlapX < OverlapY)
        {
            if(bDimensionsOnly)
                return Direction::Vertical;
            if(mRect1Pos.x < mRect2Pos.x)
                return Direction::Right;
            else
                return Direction::Left;
        }
        else
            return Direction::None;
    }
    else
        return Direction::None;
}

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

2

19.05.2017, 19:54

Wie wäre es, wenn du dir stattdessen mit Papier und Bleistift ein paar Beispiele aufmalst und dann testest, ob dein Programm alles so berechnet, wie du dir das vorstellst? Wenn nicht, dann hilft dir der Debugger. Das Forum ist nicht dafür gedacht, dass dir Leute Fehler in deinem Code suchen, den du selbst nicht verstehst. Deine Fehlerbeschreibung "funktioniert nicht gerade gut" ist auch gar nicht hilfreich.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

3

19.05.2017, 20:03

Ich würde übrigens nicht mit abstrusen Regeln für irgendwelche Abstände versuchen herauszufinden von welcher Richtung der Ball kam, sondern über die Flugrichtung des Balls. Klingt irgendwie logischer für mich.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Subsampling

Frischling

Beiträge: 39

Beruf: Anwendungsentwickler - Azubi

  • Private Nachricht senden

4

19.05.2017, 20:12

Wäre es auch nicht Möglich den Richtungsvektor zu bilden und Falls seine Länge Null wird bzw. davor Winkel berechnen und dann Eingangswinkel = Ausgangswinkel?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

5

19.05.2017, 20:15

Doch, natürlich.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

@zimmer

Alter Hase

Beiträge: 1 135

Wohnort: NRW Germany

  • Private Nachricht senden

6

19.05.2017, 20:33

kann an vielleicht auch die Werte der aktuellen Seitwärts Geschwindigkeit (Y-Achse) nutzen um die seitwärts geschwindigkeit nach dem aufprall zu bestimmen ?
edit: natürlich + die auflage position auf dem player brik

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

7

19.05.2017, 20:45

Das eigentliche Problem ist halt zu bestimmen, an welcher der 4 Seiten der Ball abprallt.

@zimmer

Alter Hase

Beiträge: 1 135

Wohnort: NRW Germany

  • Private Nachricht senden

8

19.05.2017, 20:57

der ball ist in seinem Game quadratisch und dreht sich? sonst würde ich den aufprall mit der Entfernung messen, der Radius des runden balls wäre dann die Entfernung für die Kollision.

edit: wo wird denn der würfel gedreht? Du könntest den globalen dreh-winken nehmen und der würfel reagiert dem winkel entsprechend, es gibt ja nur 4 seiten im level oder hast du eine besondere level form.

Du hast die Function von irgendwo her?
ich habe auch mal was gemalt, einfach so
»@zimmer« hat folgendes Bild angehängt:
  • online.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »@zimmer« (19.05.2017, 21:15)


BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

9

19.05.2017, 21:18

Das eigentliche Problem ist halt zu bestimmen, an welcher der 4 Seiten der Ball abprallt.
Ist eigentlich kein Problem mit simplem Raycasting/Raytracing. ;) Ich denke aber mal, du wolltest nicht sagen, dass es an sich ein Problem ist.


@zimmer: Ich habe keinen blassen Schimmer, was du uns sagen oder mit dem Bild zeigen willst.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

10

19.05.2017, 22:10

Ist eigentlich kein Problem mit simplem Raycasting/Raytracing. ;)

Ganz so trivial ist es nicht, denn der Ball ist kein Punkt. Es kommt vor, dass der Strahl die eine Seite des Blocks trifft, aber der Ball käme dort nie an, weil er vorher an der Ecke des Blocks abprallen würde.

Werbeanzeige