Kugel/Kreis prallt von Eck/Kante ab

[dino]

hä?

ich habe eine richtungsvariable als Integer und werde die berechneten gradzahlen immer runden

[Cöster]

Zitat von Sidorion:

Nichts, weil Du u.U. nicht alle 1° einen Pixel hast, sondern alle 0,576° oder alle 3,6678°, je nachdem wie groß Dein Kreisradius ist.
Bei Raduis 0 hast du 1 punkt, bei 1 sinds 4, bei 2 vielleicht 12 usw.
1. musst Du immer berechnen, weil sich der Kreis in eine der acht Haupt-und nebenachsen um 1 Pixel bewegt.

Bei 5 Grad hat man vielleicht Floats für die Koordinaten, aber die kann man ja runden und dann hat man schon alle Pixel auf der Kreisbahn. Die Speichert man sich dann in einen array oder so und fragt bei verschiebung nach rechts, links, oben oder unten dann immer jeweils die Hälfte dieses Arrays ab. Das sind dann all die Punkte, auf denen sich jetzt der Kreis befindet wo er vorher noch nicht war.

[Sidorion]

Andersrum wird ein Schuh draus. Die Koordinaten der zu testenden Pixel sind natürlich Integer, aber der Winkel, den sie aufspannen nicht. Drum würde ich deren Anzahl ermitteln (hängt vom Radius ab) und dann ihre Lage und Winkel in einem Array speichern, und zwar sortiert nach Winkel. Dann kann man abhängig vom Richtungsvektor den ersten und letzten ermitteln (Kreuzprodukt=0) und testet alle dazwischen auf Kollision.

Übrigens: Die Richtung als Integer speichern ist quatsch, da Du sonst zu große Rundungsfehler beim Abprallen bekommst.

[Cöster]

Nur die zu zeichnenden Koordinaten sind Integer. Die wirklichen Koordinaten sind natürlich Floats, bei der Kollision sollte man aber die Integer-Koordinaten prüfen, genau wie du es meintest. Die sind die gerundeten Floats.
Natürlich sind die Richtungen eigentlich Floats. Anhand dieser Float-Werte werden dann die neuen wirklichen Koordinaten (Floats) berechnet, wenn der Kreis um die Länge eines Pixels in die Richtung bewegt wird. Die Integer-Koordinaten können sich dann jeweils aber höchstens um einen Pixel verändern. Es gibt also bei den Integer-Koordinaten nur 8 mögliche Richtungen: 0, 45, 90, 135, 180, 225, 270 oder 315 Grad. Dann kommt die Kollisionsabfrage mit diesen Integer-Koordinaten.

Es wird dann auch nicht zu großen Rundungsfehlern kommen, weil alle Rechnungen mit den Floats gemacht werden. Nur bei der Kollisionsberechnung werden Integer genommen.

[dino]

ok ich machs so, nur ist mein Kreis mehr als nur ein Punkt, also kriege ich mehr als 8 Richtungen

[Cöster]

Wenn du ihn um die Länge von z.B. 5 Pixeln verschiebst, kann es natürlich sein, dass du ihn z.B. um 3 Pixel nach rechts und 4 nach unten verschiebst. Dann hättest du auch mehr als 8 Richtungen. Wenn du den Kreis zwischen den Kollisionsabfragen aber immer nur um die Länge eines Pixels in Float-Richtung verschiebst, stehen für die Integer nur 8 Richtungen zur Auswahl.

[dino]

nein der ort hab ich mir immerschon float erdacht...
nur grad wollte ich unter umständen als integer nehmen aber so genau sind wir nun

[Cöster]

Zitat von dino:

nein der ort hab ich mir immerschon float erdacht...
nur grad wollte ich unter umständen als integer nehmen aber so genau sind wir nun

??? Was? Ich versteh kein Wort.

Was sind denn die Vorteile, wenn du den Winkel als Integer nimmst? Und wieso hast du jetzt mehr als 8 Richtungen (bei integer-Koordinaten, irgendwo brauchst du die ja auch als Integer, zum Zeichnen)

[dino]

TPoint Integer: ich werde sie mir nicht als integer speichern sondern bei jedem aufruf der floatvariable runden
Richtungen: da ich einen großen Kreisund nicht bloss nen Pixel habe erhöht sich die Anzahl an Pixel, die überwacht werden müssen...
Winkel (in Grad) als Integer: ich dachtemir erst,dann beschränkt sich das ganze auf 360 verschiedene Möglichkeiten, sehe aber nun davon ab

[Cöster]

Zitat von dino:

Richtungen: da ich einen großen Kreisund nicht bloss nen Pixel habe erhöht sich die Anzahl an Pixel, die überwacht werden müssen...

Die Anzahl der Punkte natürlich. Aber du hast trotzdem nur 8 mögliche Richtungen, wenn du zwischen den Kollisionsabfragen immer nur um einen Pixel verschiebst.

Beispiel:
Du hast einen Kreis (Mittelpunkt: 0,0), den du pro Sekunde um 3 Pixel nach unten und 4 nach rechts verschiebst. Die Strecke, die in einer Sekunde zurückgelegt wird, beträgt also 5 (denn 3²+4²=5²).
Du verschiebst zwischen den Kollisionsabfragen aber immer nur um die Länge eines Pixels. Pro Sekunde machst du also 5 mal die Kollisionsabfrage:
Zuerst verschiebst du um 3/5 nach unten und 4/5 nach rechts (Mittelpunkt jetzt: 4/5, 3/5) und machst dann die Kollisionsabfrage, allerdings mit den gerundeten Koordinaten (1,1). Verschiebung also nach unten-rechts.
Dann verschiebst du nochmal genau so weit (Mittelpunkt jetzt: 8/5, 6/5). Der Mittelpunkt für die Kollisionsabfrage ist jetzt 2,1. Die Verschiebung jetzt also nur nach rechts.

So kommt man am Ende nur auf 8 mögliche Richtungen: oben, unten, rechts, links und die 4 Richtungen, die dazwischen liegen. Die Anzahl der zu überwachenden Pixel ist dann der halbe Umfang des Kreises, also pi*Radius.