Kollision: Linie und Map

[S. P. Gardebiter]

Moin.
Ich habe eine Linie, ich weiß wo sie startet und wo sie aufhört.
Dann habe ich mein Level, welches aus Arrays "besteht". (8x8 Blöcke)
Ich weiß welche Blöcke komplett leer sind und welche Blöcke solide sind oder zumindest ein Teil von ihnen solide ist. (Es sind nicht alle Tiles aus meinem Tileset Rechteckig, das ist schonmal ein Problem)

Wie würde eine Kollision zwischen Linie und Sprite funktionieren?

[Quentin]

ich denke, mit den normalen Kollisions-Befehlen wird man nicht umhin kommen, auch deine Linie als Sprite zu definieren. Oder spricht da etwas prinzipiell dagegen?

[S. P. Gardebiter]

Es hat einen eher praktischen Grund.

Bei deiner Version müsste ich 60 mal in der Sekunde einen GRABSPRITE machen, ich weiß nicht wie schnell der Befehl ist o: Dann müsste ich den Endpunkt der Kollision wissen, folglich muss ich ihn noch ausrechnen. (Ich hab mich bei meinem Startpost vertippt, ich weiß den Endpunkt nicht, nur Startpunkt und Winkel) Das ist beides im Grunde kein Problem. (Ausser GRABSPRITE ist sehr langsam, was ich mal nicht annehme)

Das echte Problem allerdings werde ich zu spüren bekommen wenn ich mal viele Bullets auf dem Bildschirm habe. (100 z.B.) Die sind zwar im Grunde keine Linien, aber fliegen in "Linien", dafür bräuchte ich den selben Algorithmus. Ich hab 64x48 Tiles. Das sind 3072, bei 100 Bullets wären das 307.200 Durchläufe. (Und das wären nur die Tiles auf dem Bildschirm! Wenn mein Level scrollt töte ich meine CPU.) Wenn ich allerdings wüsste durch welche "Tile Koordinaten" das Teil "durchfliegt", verkürzen sich die Durchläufe drastisch.

[Kitty Hello]

wenn es "solide" Rechtecke sind, könnte man das mit einer line/box Kollision machen (wäre schneller)

[S. P. Gardebiter]

Da liegt mein zweites Problem. Es muss nicht sein, dass das ganze Rechteck ausgefüllt ist.

Heißt, ich muss in etwa wie folgt vorgehen: Ich mach erstmal eine Linie/Rechteck Kollision (Folglich: Ich nehme an, dass ganze Rechteck ist gefüllt) und dann eine Pixel/Sprite Kollision (Für den 8x8 Block, in dem die Kollision passiert) um zu sehen ob da auch wirklich eine Kollision ist.
Die Frage ist wie ich das mit der Linie/Rechteck Kollision anstellen sollte, ohne meine CPU zu killen. (Bei Pixel/Sprite hätte ich schon eine Idee)

[Kitty Hello]

puh!! Dann geht nur createscreen/drawline/sprcoll.

[Trabant 500]

Ich hätte da folgende Idee:

Du sagst ja das es sich um Rechtecke handelt, die aber nur zum Teil solide sind. Das Gute daran ist ja, daß Du weißt wo sie sich im Koordinatensystem befinden und welche Ausmaße sie haben. Somit könntest Du jedes Rechteck (egal welche Form es nun genau hat) in die Außenlinien unterteilen und eine Linie-Linie-Kollisionsprüfung durchführen.
Dadurch das Du ja den Startpunkt und den Winkel hast, lässt sich der Endpunkt ganz simpel berechnen, sofern Du weißt wie lang Deine Linie werden soll.

[S. P. Gardebiter]

puh!! Dann geht nur createscreen/drawline/sprcoll.

Dann hätte ich aber wieder das Problem mit der enormen CPU Last oder wie meinst du das? o:

Somit könntest Du jedes Rechteck (egal welche Form es nun genau hat) in die Außenlinien unterteilen und eine Linie-Linie-Kollisionsprüfung durchführen.

Dann wäre das aber noch genauso rechenlastig, wenn nicht sogar noch mehr oo'

[com_1]

I hope this is what you're looking for - http://www.speedshare.org/download.php?id=8B791B2D11
Code inside.

[Kitty Hello]

I clicked on download and was flashed with lots of  .
Next time, please just attach the rar to the post for such small things.

It's working good. That's a "Point in poly" function you wrote. The only problem might be to get the polygonal shape of the pixel object now.

[Trabant 500]

Dann wäre das aber noch genauso rechenlastig, wenn nicht sogar noch mehr oo'

Eben nicht, solange Du nur die umliegenden Linien überprüfst. Dann ist das sehr schnell, aber die Optimierung überlasse ich Dir.