kollisionsabfrage
-
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 geht
Versuch 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
-
dann sagt mir bitte was besseres, was ich (ohne abitur und informatik studium) verstehe und einsetzen kann
-
Muss die Kollision denn so exakt sein?! Kannst du nicht einfach ein paar reguläre n-Ecke drum rum legen? (Quadrat ist wohl am einfachsten)
-
teil die textur in sektoren auf,wobei leere sektoren garnicht bei der kollision berücksichtigt werden.
-
otze, das is ne gute idee, danke
(wenn ichs fein genug raster wäre das ja fast das gleiche wie pixel )
würde das n vorteil bringen, wenn ich mir für jedes sprite ein bool-array anlegen würde (das angibt, ob ein pixel/eine pixelgruppe durchsichtig ist oder nicht)
und das dann prüfe (dann spar ich mir ja den zugriff auf den grafikspeicher)@optimizer
also die kollision von rechtecken und kreisen hab ich schon geproggt, funktioniert in allen kombinationen. dreiecke wärn für sowas ja noch ganz praktisch, aber das ist mir glaubich zu hoch
-
Ehhmmm, das wurde doch gesagt?! Die gefüllten Sektoren sind auch BVs.
Bye, TGGC (Zu viele Primitive hier.)
