kollisionsabfrage
-
hi
ich möchte mir eine kollisionsabfrage für 2d-spiele (directdraw) schreiben, die die pixel von zwei sprites vergleicht und so eine kollision feststellt. gibts da schnellere/effektivere möglichkeiten, als die oberfläche mit lock() und unlock() zu sperren?
-
ja, direct3D benutzen, 2 dreiecke zeichnen,darauf die textur setzen, und dann nur testen, ob ein dreieck der einen textur ein dreieck der andren trifft
DirectDraw ist tot(vorallem weil Direct3D das besser kann)
-
Pixelgenaue Kollision per CPU ist IMHO _sinnlos_.
otze schrieb:
DirectDraw ist tot(vorallem weil Direct3D das besser kann)
Mag sein, hat aber nichts mit der Sache zu tun.
Bye, TGGC \-/
-
Was willst du denn mit der pixelgenauen Kollision?!
-
bitmasks.
bei flipcode oder gamedev (oder woanders, einfach googlen) gibt's n tut dazu
-
TGGC schrieb:
Pixelgenaue Kollision per CPU ist IMHO _sinnlos_.
Achso, wenn das so ist, dann sag mal bitte wieso. Was ist den die alternative?
Crax schrieb:
bitmasks. bei flipcode oder gamedev (oder woanders, einfach googlen) gibt's n tut dazu
Hab jetzt nicht geschaut aber das ist doch das mit CPU, oder?
-
Wo liegt der Sinn? Seit wann hat die grafische Darstellung irgendwas mit der Spiellogik zu tun?
-
Optimizer schrieb:
Wo liegt der Sinn? Seit wann hat die grafische Darstellung irgendwas mit der Spiellogik zu tun?
seit dem jemand anhand der darstellung mit der logic interagiert.
rapso->greets();
-
Ob das sinnvoll ist??
-
Cool, kollidieren dann die Objekte nicht mehr, wenn ich das Spiel minimiere?
-
und wenn ein baum umfällt und niemand hört das, fällt er dann wirklich um?
fragen über fragen
rapso->greets();
-
Optimizer schrieb:
Wo liegt der Sinn? Seit wann hat die grafische Darstellung irgendwas mit der Spiellogik zu tun?
Super, wie genau die antworten manchmal hier sind.
Die Frage hieß: Wenn nicht so, wie dann alternativ realisieren?
-
rapso schrieb:
und wenn ein baum umfällt und niemand hört das, fällt er dann wirklich um?
fragen über fragen
rapso->greets();
Ähm ja, in meiner Welt schon. :p Es könnte ja schließlich nachher noch jemand kommen und feststellen, dass der Baum umgefallen ist.
Super, wie genau die antworten manchmal hier sind.
Die Frage hieß: Wenn nicht so, wie dann alternativ realisieren?Die Frage, auf die ich geantwortet habe, lautete so:
Achso, wenn das so ist, dann sag mal bitte wieso.
Es gibt verschiedene Kollisionsmodelle. Am einfachsten ist es (im 2D Raum) ein Polygon um jedes Objekt, z.B. ein Quadrat, oder ein 32-Eck zu legen, je nach Anwendung. Da brauchen wir schon mehr Informationen. Zumindest weisst du schon mal, dass Pixelkollision saugt, wenn du nicht gerade ein Worms codest.
-
also, damit ihr mich besser versteht werd ich das nochma erklären. ich fange gerade an, mich mit directX und c++ zu beschäftigen. im moment bin ich voll froh dass ich bitmaps auf den bildschirm geblittet krich und in der lage wär n 2d-spiel zu schreiben. mit direct3d werd ich mich dann später beschäftigen.
dass ich überprüfen kann, ob sich 2 rechtecke überschneiden is mir schon klar.
ich will aber jetzt innerhalb dieser rechtecke überprüfen, ob die nich vielleicht alle die colorkey-farbe haben, also durchsichtig sind. das ginge ja mit lock() und dann halt farbwerte der pixel prüfen. ich wollte jetzt von euch wissen ob das noch irgendwie schneller geht
-
Bigwill schrieb:
Achso, wenn das so ist, dann sag mal bitte wieso. Was ist den die alternative?
Weil es sowieso nur pixelgenau ist, wenn du jedes Objekt immer nur einen Pixel weit bewegst und nach jeder Bewegung überprüfst. Und das ist _lahm_.
Alternative sind Bounding Volumes, die dann entlang der Bewegungsrichtung "expandiert" werden.
Bye, TGGC \-/
-
raptile schrieb:
also, damit ihr mich besser versteht werd ich das nochma erklären. ich fange gerade an, mich mit directX und c++ zu beschäftigen. im moment bin ich voll froh dass ich bitmaps auf den bildschirm geblittet krich und in der lage wär n 2d-spiel zu schreiben. mit direct3d werd ich mich dann später beschäftigen.
dass ich überprüfen kann, ob sich 2 rechtecke überschneiden is mir schon klar.
ich will aber jetzt innerhalb dieser rechtecke überprüfen, ob die nich vielleicht alle die colorkey-farbe haben, also durchsichtig sind. das ginge ja mit lock() und dann halt farbwerte der pixel prüfen. ich wollte jetzt von euch wissen ob das noch irgendwie schneller gehtVersuch doch mal bitte, ein bisschen mehr zu abstrahieren. Die Logik des Spiels darf nicht von der Grafik abhängen. Stell dir mal vor, du willst später die Grafikengine austauschen. Dann Kollidieren die Einheiten auf einmal anders?!
Lass mal die Grafik Grafik sein und überleg dir unabhängig davon ein gescheites Kollisionssystem.
-
-
leute, ich bin ein anfänger, ich kann mit pseudo3d, vektoren und so noch nicht umgehn (bitte TGGC, berücksichtige das
) 
andere kollisionsmethoden hab ich mir schon überlegt. es geht aber darum, dass ich die form einer spielfigur nicht so einfach mit geometrischen objekten nachbilden kann (besonders wenn sie sich bewegt). die einfachste möglichkeit is doch wirklich, zu prüfen, ob sich undurchsichtige teile von zwei spielfiguren überschneiden, ich weiß garnich was ihr dagegen habt
-
raptile schrieb:
die einfachste möglichkeit is doch wirklich, zu prüfen, ob sich undurchsichtige teile von zwei spielfiguren überschneiden, ich weiß garnich was ihr dagegen habt
IMHO eben nicht.
Bye, TGGC (Reden wie die Großen)
-
wird bestimmt spassig, 2 1024*1024 texturen die zu 50% leer sind gegeneinander auf kollision zu testen
