Kollisionen [ehem. "Spiegeln?"]
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
> ich hab dir den Code mal geschickt
wo?
> Gibt man die Höhe und Breite des gesamten Bildes an wenn noch nichts transparent ist oder nur die Höhe und Breite des tatsächlich angezeigten Bildes?
ehm?
du meinst, wenn das sprite nen transparenten rand hat?
das ist eben der vorteil:
bei dieser proc kannst du die koordinaten so angeben, dass du nen transparenten rand abziehen kannst.
natürlich musst du dann auch ne dementsprechend größere X-Pos und Y-Pos angeben.
wo?
> Gibt man die Höhe und Breite des gesamten Bildes an wenn noch nichts transparent ist oder nur die Höhe und Breite des tatsächlich angezeigten Bildes?
ehm?
du meinst, wenn das sprite nen transparenten rand hat?
das ist eben der vorteil:
bei dieser proc kannst du die koordinaten so angeben, dass du nen transparenten rand abziehen kannst.
natürlich musst du dann auch ne dementsprechend größere X-Pos und Y-Pos angeben.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
yo, habn jetzt...
bevor ich mir das genau ansehe, fällt mir erstmal ein bisschen was auf:
1) procedures müssen VOR dem hauptcode stehen
2) repeat-forever is nich so dolle... mach lieberund ersetz in der Escape-Abfrage das End durch EXIT = 1
3) das sprite-laden zu testen ist gut, aber bringt nur dann wirklich was, wenn du auch drauf reagierst...
4) wenn du für alle die gleiche transparenzfarbe hast, kannst du auch VOR den Load-Befehlen einfachschreiben
so.. hab mir den rest auch angesehen...
was für ein fehler tritt denn auf?
ach... btw... wenn du deine sprite-files einfach "sprite001"-"sprite025" nennst,
kannst du die auch in ner schleife laden...
bevor ich mir das genau ansehe, fällt mir erstmal ein bisschen was auf:
1) procedures müssen VOR dem hauptcode stehen
2) repeat-forever is nich so dolle... mach lieber
Code: Alles auswählen
Until EXIT = 1
3) das sprite-laden zu testen ist gut, aber bringt nur dann wirklich was, wenn du auch drauf reagierst...
4) wenn du für alle die gleiche transparenzfarbe hast, kannst du auch VOR den Load-Befehlen einfach
Code: Alles auswählen
TransparentSpriteColor(-1, 255, 255, 0)
so.. hab mir den rest auch angesehen...
was für ein fehler tritt denn auf?
ach... btw... wenn du deine sprite-files einfach "sprite001"-"sprite025" nennst,
kannst du die auch in ner schleife laden...

Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Hab jetzt mal umgebastelt, sieht dann so aus:
0, 5 ist startpunkt der figur
300, -5 ist startpunkt des gegners
Nun geschieht aber nichts, warum?
Hatte am Anfang
aber da die koordinaten ja gleich waren wurde sofort bei programmstart eine kollision gemeldet.
Wie gekommt man denn den befehl so flexibel, dass es egal ist, wo die sich treffen bzw. dass eine Reaktion stattfinden wenn die Sprites in der Bildmitte kolllidieren?
Gruß,
Janiboy
Code: Alles auswählen
If KG_SpriteCollision( 0, 5, 100, 300, 300, -5, 100, 300 )
MessageRequester("Kollision","Es fand eine Kollision statt ",0)
EndIf
300, -5 ist startpunkt des gegners
Nun geschieht aber nichts, warum?
Hatte am Anfang
Code: Alles auswählen
If KG_SpriteCollision( 0, 5, 100, 300, 0, 5, 100, 300 )
Wie gekommt man denn den befehl so flexibel, dass es egal ist, wo die sich treffen bzw. dass eine Reaktion stattfinden wenn die Sprites in der Bildmitte kolllidieren?
Gruß,
Janiboy
mach das doch einfach separat. ob sie kollidieren ist eine sache. und ob sie sich in der bildmitte befinden (was immer du unter bildmitte verstehst..) ist eine ander sache.
Code: Alles auswählen
If KG_SpriteCollision( 0, 5, 100, 300, 300, -5, 100, 300 )
If inBildmitte(0, 5, 100, 300) Or inBildmitte(300, -5, 100, 300)
;kollision, wobei sich eines der sprites in der bildmitte befindet
Else
;kollision, irgendwo ringsrum
EndIf
EndIf
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
@#NULL
nein, absolut nicht. >__<
die kollision wird daraus ermittelt, wo sich die "testblöcke" momentan befinden.
es ist nichts weiter als eine prüfung, ob die beiden rechtecke sich überschneiden.
das ganze ist nur dann sinnvoll, wenn du Variablen einsetzt.
wenn du feste zahlen einsetzt, ist es blödsinn, weil das sieht man beim programmieren ob die gleich sind.
eine breite von 100 und eine höhe von 300 ist sowieso reichlich groß,
wieso sollte bei so riesigen blocks eine kollision interessieren?
ist deine figur wirklich 100x300 pixel groß?
so passts vielleicht eher:
wobei du Breite und Höhe der sprites am anfang direkt nach dem laden ermitteln kannst,
aber die Position der Sprites sollte sich ja dauernd ändern,
also musst du auch immer die aktuellen werte prüfen.
nein, absolut nicht. >__<
die kollision wird daraus ermittelt, wo sich die "testblöcke" momentan befinden.
es ist nichts weiter als eine prüfung, ob die beiden rechtecke sich überschneiden.
das ganze ist nur dann sinnvoll, wenn du Variablen einsetzt.
wenn du feste zahlen einsetzt, ist es blödsinn, weil das sieht man beim programmieren ob die gleich sind.
eine breite von 100 und eine höhe von 300 ist sowieso reichlich groß,
wieso sollte bei so riesigen blocks eine kollision interessieren?
ist deine figur wirklich 100x300 pixel groß?

so passts vielleicht eher:
Code: Alles auswählen
If KG_SpriteCollision( Figur_X, Figur_Y, Figur_Breite, Figur_Hoehe, Gegner_X, Gegner_Y, Gegner_Breite, Gegner_Hoehe )
aber die Position der Sprites sollte sich ja dauernd ändern,
also musst du auch immer die aktuellen werte prüfen.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
ja, mit konstanten ist mein beispiel irgendwie doof, das stimmt.
ich wollte eigentlich nur sagen, das man Kollision_? und Position_? eher getrennt untersuchen, und die ergebnisse dann nach bedarf kombinieren sollte.
aber ich weiß auch nicht ganz was Janiboy mit bildschrimmitte meint, und ich hab den thread auch nicht ganz verfolgt..
ich wollte eigentlich nur sagen, das man Kollision_? und Position_? eher getrennt untersuchen, und die ergebnisse dann nach bedarf kombinieren sollte.
aber ich weiß auch nicht ganz was Janiboy mit bildschrimmitte meint, und ich hab den thread auch nicht ganz verfolgt..
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
das hättest du vielleicht sollen... 
meine Kollisionsroutine ist eine reine positionsabfrage....
also, eine extra-positionsprüfung kann man sich schenken,
so aufwendig ist die proc nicht,
dass man sie nicht hundert mal pro frame durchhangeln könnte...

meine Kollisionsroutine ist eine reine positionsabfrage....
also, eine extra-positionsprüfung kann man sich schenken,
so aufwendig ist die proc nicht,
dass man sie nicht hundert mal pro frame durchhangeln könnte...

Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
ja, das is schon klar. ich wollte darauf hinaus:
"bzw. dass eine Reaktion stattfinden wenn die Sprites in der Bildmitte kolllidieren?"
ich dachte, er will auch wissen, in welchem bereich des screens die kollision stattfindet, also zb rechts von der mitte, links, oberhalb, oder so.
beispiel: "Chemie-Game".
3 verschiedene substanzen können zusammen reagieren und explodieren. eine davon ist in in einem kleinen bereich in der mitte des bildschrims fixiert. eine explosion findet also nur statt, wenn die beiden beweglichen substanzen kollidieren UND sich in dem bereich befinden.
..aber ich spekuliere euren thread voll, sorry
"bzw. dass eine Reaktion stattfinden wenn die Sprites in der Bildmitte kolllidieren?"
ich dachte, er will auch wissen, in welchem bereich des screens die kollision stattfindet, also zb rechts von der mitte, links, oberhalb, oder so.
beispiel: "Chemie-Game".
3 verschiedene substanzen können zusammen reagieren und explodieren. eine davon ist in in einem kleinen bereich in der mitte des bildschrims fixiert. eine explosion findet also nur statt, wenn die beiden beweglichen substanzen kollidieren UND sich in dem bereich befinden.
..aber ich spekuliere euren thread voll, sorry
