2D-Spiel Fragen und Hilfe bei Programmierung

[AMD]

Sieht doch cool aus

Es liegt halt vorallem daran, wie du deinen Ball renderst. ggf einfach mal glutSolidSphere nehmen.
Dein Programm könnte auch langsam sein, da du den Ball pro Frame immer wieder neu berechnen lässt. Optimal wäre die Geometrie nur einmal berechnet und dann nur noch verschieben mit z.B. glTranslate.

 

[Skysnake]

Ich würde den glut Post Redisplay in die idle Funktion rein packen. Da kann man das Ding dann auch schön mit nem Timer versehen, um die Max-FPS zu kappen.

Also, jetzt bewegen sich die Bälle zumindest schonmal von alleine (kommt mir n Bisschen langsam vor, aber seis drum).

So ein aktueller Ball ist im Anhang, ist es eigentlich schwer, ihn mit einer Textur zu Füllen?

WTF was ist das denn ?

Also du zeichnest deine "Kugel" schon etwas seltsam

Aber seis drum. Glut bietet wie gesagt schon fertige Kugeln an. Die sind sinnvoller zu verwenden. Ansonsten musst du mit Polygonen arbeiten, wenn du etwas texturieren willst.

Ich glaube ich leg dir mal diese Seite hier ans Herz:

Bei dir kommen viele Fragen, die dort sicherlich beantwortet werden, und zwar so, dass du es auch verstehst. Die Seite habe ich letztes Semester für meine Computergraphiks I Vorlesung auch intensiev benutzt.

OpenGL

 

[Crymes]

Ich hab irgendwie die saudumme Angewohnheit, Funktionen zu Schreiben, sie aberv nie aufzurufen
Jetzt bin ich erstmal froh, meinen allerersten Meilenstein präsentieren zu können (Ich weiss, ist nicht gerade viel).
Ne fertig kompillierte .exe ist im Anhang.

MEine jetzugen Probleme:

In der Kollisionserkennung sind noch Bugs, wie man im anhang sehen kann, funktioniert sie manchmal, manchmakl aber auch nicht.

Es gab ja ne Funktion namens gluDisk. Nur wie teile ich der mit, !wo! sie den Kreis hinzeichnen soll?

 

[Skysnake]

GLTranslate und GLRotate sind deine "Freunde"

Du zeichnest IMMER! im Ursprung der jeweiligen View, wenn du keine Koordinaten angeben kannst wie bei Lines usw.

 

[Crymes]

Also, ich nehm mich jetzt erst mal der Kollision an.
Hab jetzt nen Fehler bzg. der Abstandsberechnung gefunden, womit es schon um einiges Besser geht. (Dachte eigentlich das es ein alles oder nichts Thema werden würde, zu Früh gefreut )

Nach längerre Zeit hat ein schnellerer Ball die Angewohnheit, unter dem Bildschirm zu Verschwinden.

Und dann hab ich noch einen Grundlegenden Fehler in der Ball zu Ball Kollision, sie wollen nicht schräg abbrallen.
Das liegt aber denke ich an der verwendeten Formel.

 

[Skysnake]

Das mit dem Verschwinden geht, wenn du >= und <= verwendest. Dann kommt es nicht mehr zu dem Effekt

 

[Crymes]

An welcher Stelle? In den if abfragen habe ich eigentlich schon <= und >= genommen

Ich glaube, dass folgendes Problem entsteht:

Der Ball kollidiert rechts unten mit der Seitenwand und die neue Geschwindigkeit wird angenommen. Die nächste Position wird berechnet und der Ball ist schon zum Viertel in der Unteren Bildschirmbegrenzung.
Jetzt wird eine Kollision erkannt und das Vorzeichen wird geändert.

So weit so gut.

Doch durch ungünstige Geschwindigkeitskoordinaten kommt ist er beim nächsten Kollisionscheck noch nicht ganz aus dem Bildschirm draussen, die Geschwindigkeit wird wieder umgekehrt u.s.w.

Durch Rechenungenauigkeit ist er irgendwann im Nirwana verschwunden.

Ich hab jetzt probiert, den Ball in einer Kollisionsprüfung immer um ein Pixel weiter zu Verschieben, hat aber irgendwie nicht funktioniert.

Hab ich nen falschen Denkansatz?

 

[Skysnake]

Ja. Du musst einfach nur Berücksichtigen, von welchem Punkt er kommt. Sprich wenn er von außen den Rand durchringt, soll er einfach keine Kollision haben. Das ist die Einzige Möglichkeit, soetwas dauerhaft zu verhindern, wenn du nicht eine genau! Kollision machst, was ziemlich hässlich zu machen ist, weil du dann erstmal berechnen musst, wann das Ding stößt und bli bla blub. Mit zwei Körpern ist das noch nicht sooo das Problem, aber mit mehr um so mehr, weil du dann konsequenterweise eben auch vielfache Stöße berücksichtigen solltest.

 

[AMD]

Wie kann er nicht aus der Kollision raus kommen? So weit darfst du es garnicht erst kommen lassen.

Erstmal ein (Pseudo)Beispiel Dazu:

PositionNeu = PositionAlt + Richtung
if (PositionNeu == Kollision)
PositionNeu = PositionAlt;

Falls es also zu einer Kollsion kommt, dann rutscht du erst garnicht weiter in den "bösen" Bereich rein sondern stopst vorher. Im nächsten Durchgang dann einfach in die andere Richtung weiter gehen. Ist das soweit verständlich?

 

[Crymes]

[FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]
if[/SIZE][/FONT][/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2](ball2.position[1] + ball2.geschwindigkeit[1] < ball2.radius)
{
ball2.position[1] = ball2.radius;
}

[/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]if[/SIZE][/FONT][/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2](ball2.position[1] + ball2.geschwindigkeit[1] > bbreite - ball2.radius)
{
ball2.position[1] = bbreite - ball2.radius;
}
[/SIZE][/FONT][/SIZE][/FONT]

=Wenn der Ball jenseits des Bildschirms will, wird er auf die höchste Position, die er fliegen darf, gesetzt.

(Ist jetzt nur zur Probe bei einer Richtung).

Ich hab jetzt das Obige, was haltet ihr davon? Im 2-Minuten Test scheints im Gegensatz zu Davor zu Funktionieren.

 

[Skysnake]

Das funktioniert aber auch nur, so lange die Geschwindigkeiten nicht zu groß werden

Ist natürlich auch eine Möglichkeit, aber damit verlierst du jedwede physikalische Korrektheit, das sollte dir klar sein.

Wenn du bei wenigen Teilchen bleiben willst, wäre es besser, wenn du wirklich den Auftreffpunkt berechnest, und dann davon ausgehend streust. Aber Streuung/Kollision ist wirklich ein Thema für sich. Wenn man das wirklich korrekt machen will, dann kann man sich da Monate und Jahre mit beschäftigen ohne Probleme, bis das Zeug wirklich 1A ist UND noch immer effizient ist.

 

[AMD]

Also irgendwie versteh ich das nicht
Aber wenn es funktioniert, sei es drum...

 

[Crymes]

Aber erst dann, wenn ich die Kugeln mit einem Durchgang über den gnzen Bildschirm rasen lasse?

 

[Skysnake]

Jup, dann funktionierst definitiv nicht mehr. Richtig erkannt

Also jetzt AMDs Lösung.

Deine mit dem Zurücksetzen funktioniert immer, egal wie schnell er ist. Im Extremfall springt er halt immer von einem Ende zum nächsten, aber raus kommt er so nicht mehr.

 

[Crymes]

@AMD: Wenn der Ball von seiner aktuellen Position (im Beispiel nur y-Richtung) mit dem Geschwindigkeitsvektor auserhalb des Bildschirms landen würde, dann wird der Positionsvektor auf den maximal zur Kollision nutzbaren Wert gesetzt.
Das mach ich dann natürlich vor der Kolissionsprüfung.
Ist eigentlich fast wie in der Realität, finde ich.

 

[Crymes]

Kennt jemand eine gescheit seite, wo der nicht zentrale, elastische Stoß erklärt ist?
Ich hab jetzt schon den ganzen Tag gesucht, werd aber aus den formeln nicht schlau

 

[Dragonix]

hier stand müll <.<

 

[Crymes]

Da wurde leider nur verwiesen, dass nicht-zentrale Stöße schwierig sind und deshalb nicht behandelt werden.

Weiss sonst einer die Formel?

 

[Skysnake]

Crymes, du musst einfach nur die Streuung berechnen.

Als Näherung kannste auch einfach davon ausgehen, dass Sie zentral stoßen

 

[Crymes]

Ich hab folgendes unter der Quelle gefunden: Ratgeber zu Zweidimensionaler elastischer Stoß mit Kreisen | Physik

[I]Kommentar: Ich verwende den Dateityp "Vektor". Es handelt sich dabei um ein 
eindimensionales Array von Realzahlen. Der Index kann dabei nur die Werte 1 oder 2 
annehmen.[/I]

Funktion Skalarprodukt(x, y: Vektor): Real
{
  Skalarprodukt := x(1) * y(1) + x(2) * y(2)
}

Funktion Betrag (x: Vektor): Real
{
  Betrag := Wurzel(Skalarprodukt(x,x))
}

Funktion Abstand (x, y: Vektor): Real
{
  Abstand := Betrag(y-x)
}


Unterprogramm Stoß (Var x, y, vx, vy: Vektor)

[I]Kommentar: Beachte, dass die Parameter [U]hier[/U] mit Call-by-reference übergeben werden.[/I]

Dif,eDiv,vx_ax, vy_ax, vx_tan, vy_tan: Vektor

[I]Kommentar: Dif ist der Differenzvektor der übergebenen Parameter x und y. 
Er ist wichtig für die Bestimmung der Richtung, in der sich die Kugeln berühren. 
eDif ist ein Einheitsvektor in Richtung von Dif. Den brauchen wir, um die 
Komponentenzerlegung durchführen zu können.
vx_ax und vy_ax sind die Geschwindigkeitsvektoren in axialer Richtung, 
vx_tan und vy_tan in tangentialer Richtung.[/I]

{
  Dif := y - x
  eDif := Dif * (1/Betrag(Dif))

  vx_ax := Skalarprodukt(eDif,vx) * eDif
  vy_ax := Skalarprodukt(eDif,vy) * eDif
  vx_tan := vx - vx_ax
  vy_tan := vy - vy_ax

[I]Kommentar: Das war die Komponentenzerlegung[/I] 
  
  vx := vx_tan + vy_ax
  vy := vy_tan + vx_ax

[I]Kommentar: Die tangentialen Komponenten werden beibehalten, die axialen 
Komponenten ausgetauscht.[/I]
}

Hauptprogramm
{
  t := 0
  Eingabe Pos1, Pos2, v1, v2: Vektor
  Eingabe DeltaT,Dauer: Real
  Eingabe Radius: Real
  
  Wiederhole solange t<Dauer
    {
      t := t + DeltaT
      Pos1 := Pos1 + v1*DeltaT
      Pos2 := Pos2 + v2*DeltaT
      Falls Abstand(Pos1, Pos2) <= 2*Radius
        {
          Stoß (Pos1, Pos2, v1, v2)
        }
      Ausgabe Pos1, Pos2
    }
}

Ist das richtig?