 |
JLI Spieleprogrammierung
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Hasenfuß
Gast
|
 Verfasst am: 19.08.2002, 15:47 Titel: Kollisionsabfrage |
 |
|
| Hallo kann mir jemand sagen ob es sowas wie Kollisionsabfragen bei Farben gibt? Hab mir das so vorgestellt das dann z.B. bei einem Spiel nicht passierbare Bereiche einfach in einer bestimmten Farbe gezeichnet werden, die dann von der Kollisionsabfrage erkannt werden. |
|
| Nach oben |
|
 |
Sören
JLI Master Trainee
Anmeldedatum: 26.07.2002
Beiträge: 647
Wohnort: Bonn
Medaillen: Keine
|
| Verfasst am: 19.08.2002, 15:59 Titel: |
|
|
Hi!
Klar gibt es sowas! Das Prinzip der Pixelgenauen Kollisionserkennung arbeitet ja mit Farben! Wenn sich also 2 Farben überschneiden und beide ungleich des Colorkeys sind, ist eine Kollision aufgetreten! |
|
| Nach oben |
|
|
Hasenfuß
Gast
|
| Verfasst am: 19.08.2002, 16:02 Titel: |
|
|
| Danke aber so ganz hab ich des jetzt net verstanden kannst du mir des bitte noch n bissl genauer erklären? |
|
| Nach oben |
|
|
Michael
JLI'ler
Anmeldedatum: 20.07.2002
Beiträge: 173
Wohnort: Münster / NRW
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 09:17 Titel: |
|
|
Wenn du eine Kollisionserkennung durchführen willst, machst du zunächst eine sog. Groberkennung. Hierzu benutzt die einfach die beiden Rechtecksbereiche, die die beiden zu prüfenden Ausschnitte enthalten. Wenn sich diese Rechtecke überlappen, musst du eine Feinerkennung machen mit Pixelvergleich und so weiter. Prinzipiell ist dieser Vergleich so:
Du überprüfst, ob jedes Pixel auf der Surface wo beide "Kollisionspartner" drauf sind die gleiche Farbe hat wie die ursprüngliche Surface. ist dies nicht der fall und die Farbe ist nicht gleich der Colorkey-Farbe des zweiten "Kollisionspartners", dann hast du eine echte Kollision.
Verstanden? Wenn nicht frag nochmal genau nach!
_________________
Es geht auch ohne  |
|
| Nach oben |
|
|
Hasenfuß
Gast
|
| Verfasst am: 20.08.2002, 09:53 Titel: |
|
|
Wenn ich das jetzt richtig verstanden hab, dann muss ich die primäre Oberfläche und die beiden Spriteoberflächen sperren. Aber wie kann ich die einzelnen Pixel vergleichen?? Kannst du mir vielleicht einen kleinen Codeausschnitt zeigen?
Danke schonmal im voraus!!  |
|
| Nach oben |
|
|
AFE-GmdG
JLI MVP
Alter: 45
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 10:37 Titel: |
|
|
Die Primäre Oberfläche mußt du nicht unbedingt sperren, nur die Bitmaps oder Sprites. Danach berechnet man den Versatz, also den Wert, der die beiden Sprites auseinanderliegen.
Pseudocode:
| Code: |
int x1, y1, x2, y2; // Schleifenvariablen
LPDDSPRITE Sprite1, Sprite2; // die Sprites
int px1, py1, px2, py2; // Position der Spiites
int dx, dy; // Differenz zwischen Sprite1 und Sprite2;
dx=px2-px1; // Versatz berechnen
dy=py2-py1;
// Ist der Versatz Positiv, liest Sprite1 weiter links als Sprite2, wenn negativ weiter rechts. Analog für Y und oben/unten...
if(dx>0) {
for(x1=sprite1.width-dx,x2=0; x1<Sprite1.width&&x2<Sprite2.width; x1++, x2++) {
if(dy>0) {
for(y1=sprite^.height-dy,y2=0; y1<Sprite1.height&&y2<Sprite2.height; y1++, y2++) {
if(Sprite1.pixels[x1][y1]!=Colorkey&&(Sprite2.pixels[x2][y2]!=Colorkey) {
//Kollisionsbehandlung
}
}
} else {
//Teste wie oben, nur das Sprite1 tiefer als Sprite2 ist. (Forschleife muß umgestellt werden)
}
}
} else {
// Teste wie oben, nur das Sprite1 weiter rechts ist, als Sprite2.
// Y muß auch noch getestet werden!
}
|
Dies ist nur Pseudocode, der Zeigt, wie man soetwas machen kann, der aber so nicht ausgeführt werden kann. Wenn du die For-Schleife verstanden hast, kannst du die anderen daraus herleiten.
Der Code ist auch nicht geschwindigkeitsoptimiert, also vorher schon testen, ob sich die Sprites überhaupt berühren können (Boundingboxen)
Weitere Optimierungsmöglichkeiten sind z.B. Farbmaskenfelder. Jedes Sprite hat ein 2-Dimensiomales Feld, von Bits, wobei ein Bit gesetzt ist, wenn der dazugehörige Bildpunkt gemalt werden soll und umgekehrt. Diese Felder könnenn sich ja im normalem Speicher befinden und müssen z.B. nicht gesperrt werden.
AFE-GmdG[/code]
_________________
| CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
| Nach oben |
|
|
Hasenfuß
Senior JLI'ler
Alter: 37
Anmeldedatum: 20.08.2002
Beiträge: 291
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 11:51 Titel: |
|
|
DANKE!!!!!!
Jetzt hab ichs so gut wie verstanden. Aber ist "Colorkey" wirklich ne Colorkeystruktur oder ein ganz normaler RGB-Wert? |
|
| Nach oben |
|
|
AFE-GmdG
JLI MVP
Alter: 45
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 13:31 Titel: |
|
|
Ist in Wirklichkeit ne Struktur, in der eine Untere und eine Obere Farbe definiert werden kann. Bitte Frag nicht, wie die Zwischenwerte berechnet / ausgewertet werden, das weiß ich nicht, ich habe bisher immer die gleiche Farbe für "oben" und "unten" verwendet.
Wie gesagt, mit einem Farbmaskenfeld ersparst du dir die ganze sache mit den Colorkeys - Obendrein kann man auch noch eine Andere Form wählen...
AFE-GmdG
_________________
| CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
| Nach oben |
|
|
Hasenfuß
Senior JLI'ler
Alter: 37
Anmeldedatum: 20.08.2002
Beiträge: 291
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 13:48 Titel: |
|
|
| Aber die Struktur is vom Typ DDCOLORKEY, und die beiden Farbwerte wären dann dwColorSpaceLowValue und ..HighValue oder? |
|
| Nach oben |
|
|
Michael
JLI'ler
Anmeldedatum: 20.07.2002
Beiträge: 173
Wohnort: Münster / NRW
Medaillen: Keine
|
| Verfasst am: 20.08.2002, 14:06 Titel: |
|
|
Richtig. Die beiden Farbwerte sind dann abhängig von der Einrichtung 16 oder 32Bit-Farbwerte
_________________
Es geht auch ohne |
|
| Nach oben |
|
|
Mr. Anderson
Gast
|
| Verfasst am: 20.08.2002, 21:39 Titel: andere methode |
|
|
du könntest auch einfach in der kartenstruktur einen bereich für trigger oder ähnliches (also auch nicht passierbare bereiche) anlegen.
dafür verwendest du am besten ein unsigned long und die zweierpotenzen von 2^1 bis 2^32 als schalter. die definierst du als konstanten und ORst sie dann (wie bei windows, | , logisches OR). wenn du das ganze dann später im spiel nacheinander mit den einzelnen konstanten ANDest ( & , logisches AND). damit checkst du, ob ein flag gesetzt ist und führst dann bestimmte operationen aus. wenn der spieler z.b. die figur auf feld 42 der karte bewegen will, guckst du nach, ob er das darf, ansonsten änderst du die position einfach nicht. das müsstest du bei wegfindungsroutinen berücksichtigen, indem du z.b. die wegkosten auf -1 setzt und das feld so als unpassierbar markierst.
sähe dann ungefähr so aus:
| Code: |
struct mapcoord
{
unsigned long flags;
long waycosts;
/*
anderer schrott
*/
}
//im mapeditor:
/*
...
*/
map[42]->flags = UNPASSABLE | SOUND_NOPASS;
map[42]->waycosts = -1;
//im spiel dann:
/*
...
*/
if(movepos->flags & UNPASSABLE)/*gibt 1 (true),wenn UNPASSABLE gesetzt
*/
{
//spieler nicht bewegen
}
else if(//andere abfragen)
/*
...
*/ |
ist pseudocode! |
|
| Nach oben |
|
|
Hasenfuß
Senior JLI'ler
Alter: 37
Anmeldedatum: 20.08.2002
Beiträge: 291
Medaillen: Keine
|
| Verfasst am: 21.08.2002, 10:39 Titel: |
|
|
| Ich habs geschafft!!! Danke an alle die mir geholfen haben. |
|
| Nach oben |
|
|
AFE-GmdG
JLI MVP
Alter: 45
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine
|
| Verfasst am: 21.08.2002, 15:58 Titel: |
|
|
Bitte, Bitte.
Dafür sind wir doch da. Solange eine Frage ordendlich gestellt ist, bin ich immer gerne bereit, eine Antwort darauf zu geben. Nur Dummes Angeschnauze und hingeworfene Satzteile werde ich nicht beachten.
Zum Glück ist das hier noch nicht so häufig vorgekommen...
AFE-GmdG
_________________
| CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
| Nach oben |
|
|
Hazel
JLI MVP
Alter: 39
Anmeldedatum: 19.07.2002
Beiträge: 1761
Medaillen: Keine
|
| Verfasst am: 21.08.2002, 16:19 Titel: |
|
|
Finde ich auch... *zum USF und DSB guck* ... am besten sind immer noch english-sprachige gamedev. Foren und Chats.
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R
|
|
| Nach oben |
|
|
DaN00b
JLI'ler
Anmeldedatum: 10.08.2002
Beiträge: 159
Medaillen: Keine
|
| Verfasst am: 06.09.2002, 13:49 Titel: |
|
|
ich hab nu auch eine frage dazu:
ich hab wie im buch (kapitel 19) mein surface gelockt und den zeiger auf das pixelfeld initialisiert
WORD* wlpSurface = (WORD*)DDSurfDesc.lpSurface;
ich hätte da mal gern ein zwei zahlenbeispiele damit ich mich mit dem pitch etc besser zurecht kommen
nehmen wir mal 640*480 an das surface das ich gelockt hab hat en width von 20px und en height von 30px und liegt an und des surface ist an x=300 y=200
wie greife ich nun über wlpSurface auf z.b. dem Pixel x=10 y=15 des Surfaces zu?
_________________
Carpe Diem - Seize the day - Nütze den Tag! |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de |
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
