Break-Game, Kugel auf Rechtecklanden lassen ...

[KleinAmann]

hey,

würde mich über eine 2D engine sehr freuen

wäre cool wenn du mla von beiden den Link postest.

Vielen Dank

Mfg Domi

[mimi]

naja die engine läuft nur unter Lazarus. Ich habe sie hier gerade nichte gefunden.
ich lade sie später hoch. Aber ich weiß nicht so recht, ob sie dir weiter helfen wird.

[mimi]

So hier habe ich die "2D Engine" gerade eben hochgeladen:
http://www.delphipraxis.net/posting.php#top

Ich habe zwar auch ein eigenen BreakOut Clone geschrieben, aber ich glaube den veröffentliche ich erst später, weil der auf das GamePack basiert, welches intern meine "2D Engine" nutzt.

[Medium]

Wenn man mit PtInRect arbeitet muss man aber mindestens von einem der möglichen Kollisionspartner wirklich JEDEN Pixel einzeln überprüfen, oder aber eine geschlossene "Sensorlinie" abprüfen. Beides Gefummel und nicht wirklich performant, und wenn das Rect zu schmal ist, bzw. der Ball zu schnell kann er dir dabei immer noch einfach durchfliegen. Das lässt sich dann nur noch mit Schnittpunktbestimmung umgehen, welche zudem nicht nur die reine Kollision feststellt, sondern auch gleich Infos zur korrekten Reflexion liefert. Auf Pixeltests basierende Kollisionen halte ich für grausiges Gefrickel (zumindest wenn darauf hin etwas "abprallen" soll)

[mimi]

Nein, das ist nicht so richtig.

Wenn du den Ball bewegen möchtest, weißt du ja wohin. Jetzt muss du nur noch in einer schleife prüfen ob dort schon ein Objekt ist oder nicht. Rate mal wie das Andorra macht ? oder ich bei meiner 2D Engine.

Die heutigen Rechner können das. und du wirst warscheinlich nicht 10000 Objekte haben. Wenn es hoch kommt wirst du evlt. gerade mal 100 oder 200 Objekte habe.

und die Funktion prüft auch nur ob im angeben Viereck ein Punkt liegt. Das ist sehr viel schneller als jeden Pixel zu prüfen.

Du hast ein Viereck und die Funktion prüft jetzt einfach nur noch ob in diesem Viereck die angeben Koordinaten liegen.
Mehr nicht. Das sollte bei den meisten Rechner überhaupt kein Problem da stellen.


Und wie möchtest du es sonst lösen ?
In deinen Fall könntest du auch noch ein zweites BitMap einfügen, wo du nur unbewegliche Objekte rein tust.
die werden dann in einer Farbe gezeichnet, der Rest in einer anderen.

Wenn du den Ball bewegt, könntest du einfach nach schauen ob dort frei ist oder nicht. mit Hilfe von Pixels von Canvas.
Aber diese Lösung wird viel mehr Speicher brauchen.

Zum Aprallen hier gibt es auch ein Beispiel in der "Code Lib" dazu:
http://www.delphipraxis.net/internal...ight=abprallen

[Medium]

Zitat von mimi:

Wenn du den Ball bewegen möchtest, weißt du ja wohin. Jetzt muss du nur noch in einer schleife prüfen ob dort schon ein Objekt ist oder nicht. Rate mal wie das Andorra macht ? oder ich bei meiner 2D Engine.

*schüttel* ("Weil hunderttausende Fliegen..." man kennt den Spruch ) Es geht halt auch ohne häßliche Pixelschritt-Schleife.

Zitat von mimi:

Die heutigen Rechner können das. und du wirst warscheinlich nicht 10000 Objekte haben. Wenn es hoch kommt wirst du evlt. gerade mal 100 oder 200 Objekte habe.

Genau, deswegen schreibe ich auch erstmal in jedem meiner Programme mindestens 1GiB Schrott in den Speicher, weil die meisten haben ja genug davon.

Zitat von mimi:

und die Funktion prüft auch nur ob im angeben Viereck ein Punkt liegt. Das ist sehr viel schneller als jeden Pixel zu prüfen.

Was ist aber, wenn der "Ball" in diesem Fall größer als nur einen Pixel ist? Es geht nicht um jedes Pixel im Rechteck, sondern in dem des zweiten Objektes.

Zitat von mimi:

Du hast ein Viereck und die Funktion prüft jetzt einfach nur noch ob in diesem Viereck die angeben Koordinaten liegen.
Mehr nicht. Das sollte bei den meisten Rechner überhaupt kein Problem da stellen.

Wenn man es ein paar tausend bis zigtausend Mal pro Sekundenbruchteil macht schon, sei versichert.

Zitat von mimi:

Und wie möchtest du es sonst lösen ?

So!

Zitat von mimi:

Wenn du den Ball bewegt, könntest du einfach nach schauen ob dort frei ist oder nicht. mit Hilfe von Pixels von Canvas. Aber diese Lösung wird viel mehr Speicher brauchen.

Canvas.Pixels - genau der richtige Partner, wenn man einen PC mal so richtig ausbremsen möchte. (Und SO viel mehr Speicher braucht das nicht. Man hat ja so viel davon!)


Versteh mich nicht falsch, ich will niemanden einfach nur anmachen, aber was du da geschrieben hast ist imho eine echte Sammlung von no-gos, die man so nicht stehen lassen kann.

[mimi]

Wenn du meinst. Man kann es auch übertreiben das stimmt. Ich habe mir den Code jetzt nicht angesehen, weil unter Linux kann ich noch nicht ohne weiteres neue Rar Formate entpacken. Ich habe nur ein Komandozeilen tool.
Wenn ich mal lust habe mache ich das.

[Medium]

GIF <> RAR

[mimi]

Hast recht, habe den falschen Anhang angeschaut.
Ich verstehe zwar das bild nicht so recht, aber ich glaube wie meinen im Grunde das gleiche, nur reden wir gerade aneinander vorbei. So wie das Bild aussieht meinte ich das eigentlich auch. So macht das ja auch ptinRect. Schau dir mal die Funktion an.

[Medium]

PtInRect macht folgendes:
Es nimmt einen 2D-Punkt entgegen, und ein Rect. Dann wird die X-Koordinate des Punktes auf größer/kleiner mit der linken/rechten Begrenzung des Rects verglichen, sowie die Y-Koordinate mit der oberen/unteren Grenze. Das ergebnis ist die 4 Vergleiche and-verknüpft.
Das muss man nun für jeden Punkt des zu testenden Objektes machen, und für jeden Punkt den dieses im Laufe der Bewegung einnehmen wird.

Was ich mache ist etwas völlig anderes. Ich nehme den Richtungsvektor des beweglichen Objektes, und erstelle mir eine Gerade auf den Ballmittelpunkt gestütz, setzte diese gleich mit der Gerade die die Kollisionsoberfläche bildet, und erhalte nach lösen des kleinen LGS einen Parameter, der angibt wie oft ich den Richtungsverktor "malnehmen" muss, um auf die Oberfläche zu treffen. Ist der Parameter kleinergleich eins, tritt die Kollision im anstehenden Schritt auf, und mit den dann vorhandenen Daten kann man zudem leicht ein physikalisch korrektes Abprallverhalten trotz mögl. großschrittiger Bewegung errechnen.

Was man mit PtInRect macht ist Pixelweise rumfrickeln, was ich mache ist einfache lineare Algebra. Vorteile letztrer Variante:
- Konstanter Zeitverbrauch (man muss nicht u.U. alle Pixel in einer Diagonalen quer über den Bildschirm abstesten)
- Kollision wird IMMER gefunden, selbst wenn das Objekt so klein/schnell ist, dass es sonst weit über den Kollisionspartner "springen" würde
- Analytischer statt diskreter Ansatz
- Universell einsetzbar (Die Kollisionspartner müssen keine rechtwinkligen Vierecke oder Kugeln sein, auch wenn es die einfachsten Fälle sind)

Nachteile:
- Man muss in der Schule bei Vektorrechnung gerade wach gewesen sein, zumindest halb


Und wie vorher schon erwähnt, kann man in diesem speziellen Fall einige sehr deutliche Vereinfachungen machen, da man immer mit horizontalen Linien Kollidiert, diese keine Eigenbewegung haben, und die Präzision sehr wahrscheinlich ausreichen wird. Wie, hatte ich ja auch schon geschrieben.

Der TE müsste nur mal ein wenig genauer werden als "geht nicht", dann könnte man vermutlich sogar konkret weiter helfen