LockRect -> invalid call
-
der pitch ist doch abhängig von der Farbtiefe, die ich im falle meines programmes auf 32bit festgelegt habe. sowohl der backbuffer als auch mein offscreenplainsurface haben 32bit.
UnlockRect habe ich hier nur nicht mit aufgeführt. im programm stehts, aber da kommt der nie hin, weil er beim schreiben der pixeldaten hängen bleibt.
-
Der Pitch hängt natürlich mit der Farbtiefe zusammen er ist aber nicht notwendigerweise einfach Breite * sizeof(Pixel), dann bräuchte man ja keinen extra Pitch oder?
. Je nachdem wie die Graka das Ding im Speicher alignen will etc. kann der Pitch einfach irgendwas sein...
Wegen dem UnlockRect(): Wollte nur sichergehen dass es auch nach dem Schreiben steht und nicht davor...
-
Das UnlockRect kommt auch definitiv nach dem Schreiben.
Hm, wegen dem Pitch. Soweit ich weiß gibt es den, weil noch additionale informationen zu den Pixeln gespeichert werden. Demnach gibt der Pitch die Zeilen Länge inclusive der additionalen infos in byte an.
Ist meine berechnung bezüglich des Pitch und die anschließende adressierung mit dem neuen pitch verkehrt?
-
shane_da_progga schrieb:
Ist meine berechnung bezüglich des Pitch und die anschließende adressierung mit dem neuen pitch verkehrt?
Sie basiert auf der nicht notwendigerweise korrekten Annahme dass der Pitch ein Vielfaches von 4 ist. Aber naja, üblicherweise ist das der Fall, also wird er Fehler eher nicht dort zu suchen sein...
-
Nun, ich habe mir selber nicht besonders viele gedanken zu dem Pitch gemacht, da ich der annamhme war, wdas dieser im Buch korrekt berechnet wird.
Aber mal angenommen er ist falsch berechnet, wie berechne ich den Pitch dann so, dass ich in als offset in meiner adressierung benutzen kann? Ich meine, wie finde ich raus, inwieweit er nun von meiner farbtiefe abhängig ist oder nicht.
Da ich im prinzip nichs anderes falsch machen kann, ist das meine einzige hoffnung^^
es sei denn, dass irgendwelche flags gesetzt werden müssen, auf die das buch, aus gründen der nicht-kompetenz, nicht eingegangen ist.
Ich finds echt schade, dass der code aus dem buch fehlerhaft ist.
-
Wo liegt das Problem? Der Pitch ist die Anzahl an Bytes die eine Zeile belegt. Das ist alles. Um zur nächsten Zeile zu gelangen spul einfach um Pitch Bytes vor und nicht Pitch / 4 DWORDs...
-
um einzelne pixel zu adressieren ist es notwendig das entsprechende byte in der zeile zu ermitteln, da muss ich den pitch früher oder später teilen.
-
Nein musst du nicht. Einzelne Pixel adressierst du mit x und y Koordinaten. Die y Koordinate entspricht der Zeile. y * Pitch gibt dir damit den Byteoffset von pBits zum Zeilenanfang. Und von dort gehst du dann x * sizeof(Pixel) (in deinem Fall also x DWORDs) weiter um zu deinem Pixel zu gelangen. An deiner Stelle würd ich sowieso mal diese ganze komische Indexberechnung da überprüfen, höchstwahrscheinlich liegt der Fehler eh dort. Check mal ob das was du da ausrechnest überhaupt noch in der Surface drinnen liegt...
-
OK. Das sind echt solide Informationen^^ danke, hab mich eh die ganze zeit gefragt, warum das im buch so steht. Probier das mal sofort aus.
-
Hmm, schade, aber gibt genau den gleichen fehler aus. Meine Indexbrechnung:
int index = ((int)m_y * Pitch + (int)(m_x * 4));Der Pitch geht dabei unverändert in die Berechnung ein. m_y ist die y koordinate des Sterns, m_x entsprechend die x-Koordinate. /4, weil sizeof(D3DCOLOR_X8R8G8B8) letztenendes auch nur 4 rausschmeißt.
-
Der Unterschied zwischen einem Index und einer Adresse ist dir bekannt!? Was ich meinte war folgendes:
DWORD* pixel = reinterpret_cast<DWORD*>(static_cast<char*>(LockedRect.pBits) + y * LockedRect.Pitch) + x;
-
ja, der unterschied ist mir bekannt...
Ich habe einen index berechnet, um via pBits[index] eine Adresse zu erhalten. pBits ist ein Zeiger auf das erste Byte der Surface und man kann diesen auch als array von Bytes behandeln. Demnach muss man nur berechnen, das wievielte Byte ich veränder/setzen möchte und dieses via pBits[Index] ansprechen.
-
Stimmt, sry hab deinen Code zu flüchtig gelesen
-
Macht ja nix. Ich hätte wohl auch keinen Bock richtig hin zu lesen, wenn ich den mist schon 100 mal gemacht hätte
Ich gehe jetzt mal davon aus, das die Adressierung des Pixels klappt, dann gibt es immer noch den blöden Fehler. Ergo gibt es entweder eine Möglichkeit die Zugriffsrechte zu beeinflussen oder der Surface ist eben doch nicht richtig gelockt, obwohl kein Fehler ausgegeben wird.Natürlich gibt es auch noch Option3, dass Directx auf dem Gebiet Veränderungen durchlaufen hat, die dem Buch selbstredend vorenthalten sind, da es zu directx9 Zeiten geschrieben wurde.
-
Ich würde zuerst mal Option 4 überprüfen: Du greifst auf Speicher zu der außerhalb der Surface liegt weil deine Koordinaten müll sind.
-
hm.
ich kann nur sagen: wenn ich von LockRect() "success" bekommen habe, dann hat's bei mir auch immer funktioniert.
probleme hatte ich nur manchmal dass ich überhaupt "success" von LockRect() zurückbekomme - einige kombinationen aus surface-flags und pixel-format wollten da einfach nicht mitmachen.
soll heissen: untersuch wirklich mal "option 4"
-
Ok. Hab es hinbekommen. Die Koordinaten waren ok, allerdings haben die vergessen abzufragen, ob die Koordinate, welche ich zeichnen möchte auf dem Surface liegt. hab das zusätzlich abgefragt und jetzt läuft es. Danke für eure hilfe Dot und Hustbaer.
so long
euer Shane
-
Also waren die Koordinaten Müll :p
Anyway, am Besten du vergisst das alles jetzt ganz schnell wieder und renderst deine Sterne als Pointlist
-
In der Tat^^ einiger der Koordinaten waren sehr crapy. Umso enttäuschender, das das aus nem eigentlich angesehenen Buch stammt.
