Warum funzt Pixelputten mit Surface->Lock nicht???

D*nm*n

Hi,

nach unzähligen Versuchen, mit Surface->Lock einen Pixel auf den Screen zu zeichnen hab' ich jetzt die Schnautze voll: Warum, verdammt nochmal, funktioniert das nicht??? Kann es sein, dass der BCB das nicht hinkriegt, oder das DX5 das noch nicht drauf hat??? Ich habe vor ein paar Monaten schon mehrmals deswegen gepostet (nochmals vielen Dank, nach ewigem Rückfragen kam ich mir irgendwann aber zu blöd vor, immer weiter zu fragen) und zig Tutorials aus dem Internet runtergeladen, ich hab's mit buffer[x+yddsd.lPitch] = Farbe* und auch noch viel komplizierteren Sachen, bei denen vorher z.B. genau die Farbtiefe erkannt wird, bzw. ermittelt wird, ob es RGB555 oder RGB565 ist, probiert, aber ich krieg's einfach nicht hin.
Ich werde noch wahnsinnig!!!
Okay, ihr werdet mir wohl kaum helfen können, aber hat vielleicht irgendeiner auch solche Probleme (gehabt) ??? Wenn ja, dann bitte postet und (falls ihr könnt) helft mir!!!
B I T T E ! ! !

------------------
Mfg, D@nm@n

[Diese Nachricht wurde von D@nm@n am 02-06-2001 editiert.]

hamPster

Bei mir geht's auch net... Und das trotz VC++ und obwohl ich das Programm (insbesondere die PutPixel-Funktion) fast komplett vom Buch von Stefan Zerbst übernommen hab'. Er zeichnet keinen Pixel, und wenn man das Programm beendet, gibt's auch noch 'ne schöne Fehlermeldung. Und der Fehler scheint genau von der Zeile verursacht zu sein, wo man der entsprechenden Speicherzelle einen Wert zuweist...

------------------
Jesus lebt

TGGC

bei mir funzt es...

einen (total chaotischen) Source gibt es hier: http://www.fh-merseburg.de/~roesch/mirror/x/stud/zips/ballzsrc.zip

D*nm*n

Okay, wenigstens weis ich jetzt, dass ich nicht der einzige bin, bei dem's net funzt http://www.c-plusplus.net/ubb/ubb/smile.gif ! Wenn niemand das selbe Problem hatte, und es gelöst hat, mach ich's halt weiter mit SetPixel, auf meinem Celeron 500 funzen 4 x 70 Pixel + pixelgenaue Kollisionsabfrage (pro Frame!) in 1024 x 768 x 16 bit mit vollen 85 FPS (und DDraw kann bei mir seltsamerweise net schneller...), von daher reicht das (zur Not) auch aus... trotzdem wär's mir lieber, wenn die Surface->Lock-Methode funzen würde...

------------------
Mfg, D@nm@n

FinalBrain

Ich denke, dass du einen Fehler
bei der Berechnung der Speicher-
Adresse machst!! Wenn du keine
Taiwanische Hardcore-NoName
Marke "Eigenbau" Grafikkarte hast, dann
denke ich wird es auch bei dir funzen!!
Das DirectDraw nicht schneller als
setPixel ist, liegt daran, dass
DirectDraw sich nach der
Hertz-Zahl des Monitors richtet, und
das ist auch gut so!! Bei großen
Draw-Aktionen wird dir auffallen, dass
DirectDraw doch schneller ist !!
Poste mir mal deinen GANZEN Code
und ich werde den Fehler finden, denn
ein Pixel in DirectDraw zu zeichnen
ist einfach!

MFG
FinalBrain

hamPster

Zitat:

Original erstellt von FinalBrain:
**Ich denke, dass du einen Fehler
bei der Berechnung der Speicher-
Adresse machst!! Wenn du keine
Taiwanische Hardcore-NoName
Marke "Eigenbau" Grafikkarte hast, dann
denke ich wird es auch bei dir funzen!!
Das DirectDraw nicht schneller als
setPixel ist, liegt daran, dass
DirectDraw sich nach der
Hertz-Zahl des Monitors richtet, und
das ist auch gut so!! Bei großen
Draw-Aktionen wird dir auffallen, dass
DirectDraw doch schneller ist !!
Poste mir mal deinen GANZEN Code
und ich werde den Fehler finden, denn
ein Pixel in DirectDraw zu zeichnen
ist einfach!

MFG
FinalBrain

**

He, ich hab' 'ne ATi Radeon, ich würde nicht sagen, dass das 'ne Noname GraKa ist.
Und was die Speicherbelegung angeht: Der Speicher wird doch automatisch zugewiesen, d.h. ich hab' da doch gar keinen Einfluss drauf, oder?
Ich würde wirklich gerne Pixel putten...

------------------
Jesus lebt

FinalBrain

Poste mir mal deinen Pixelput-Code, der
nicht geht und ich probiere dir daraus
was zu basteln, dass dann auch bei dir geht !! Kannst du denn auch nicht blitten ??

MFG
FinalBrain

hamPster

Zitat:

Original erstellt von FinalBrain:
**Poste mir mal deinen Pixelput-Code, der
nicht geht und ich probiere dir daraus
was zu basteln, dass dann auch bei dir geht !! Kannst du denn auch nicht blitten ??

MFG
FinalBrain

**

Code:

bool PutPixel(LPDIRECTDRAWSURFACE7 lpDDSurf, int x, int y, UCHAR Farbe)

{

int ZeilenBreite;

UCHAR* Vram;

DDSURFACEDESC2 surfacedesc;



ZeroMemory(&surfacedesc, sizeof(surfacedesc));

surfacedesc.dwSize = sizeof(surfacedesc);



lpDDSurf->Lock(NULL, &surfacedesc, DDLOCK\_SURFACEMEMORYPTR | DDLOCK\_WAIT, NULL);

ZeilenBreite = surfacedesc.lPitch;



Vram = (UCHAR*)surfacedesc.lpSurface;

Vram[x + y * ZeilenBreite] = Farbe;

lpDDSurf->Unlock(NULL);

return true;

}

[/code]

Blitten geht, jedenfalls um den Puffer zu löschen...
Der Fehler muss irgendwie in der Speicheradressierung liegen...

------------------
Jesus lebt

hamPster

Weiß denn niemand einen Rat?

------------------
Jesus lebt

D*nm*n

Den gleichen Code (na ja, nicht haargenau den gleichen, aber die gleiche Methode) nehm' ich auch!!! Und ich hab' ne Voodoo3, also auch keine Noname-Grafikkarte. Das mit den falschen Speicherzuweisungen kann eigentlisch ausgeschlossen werden, da ich es schon mit einigen Methoden probiert habe (siehe auch mein 1. posting!)!

Wo wir gerade beim blitten sind: Ist es eigentlich genauso schnell, einen Pixel zu blitten??? Ich brauche das ganze nämlich für einen Sternenhintergrund, da könnte ich doch auch ein 1x1 Bitmap anlegen und es blitten (oder ist da wiederum SetPixel schneller?)!?!

------------------
Mfg, D@nm@n

[Diese Nachricht wurde von D@nm@n am 09-06-2001 editiert.]

D*nm*n

Beim weiteren Durchlesen durch das Forum ist mir noch was aufgefallen: Müssen ZeroMemory und x = sizeof(x) immer dastehen??? Das habe ich aus Faulheit (glaube ich) immer weggelassen http://www.c-plusplus.net/ubb/ubb/rolleyes.gif...
Und noch was: Muss vor dem Unlocken nicht noch einmal (UCHAR)surfacedesc.lpSurface = Vram;* stehen???

------------------
Mfg, D@nm@n

D*nm*n

He, es funzt http://www.c-plusplus.net/ubb/ubb/smile.gif http://www.c-plusplus.net/ubb/ubb/smile.gif http://www.c-plusplus.net/ubb/ubb/smile.gif !!! Es lag tatsächlich an dem fehlenden ZeroMemory, etc. Ich dachte die ganze Zeit, das wäre nur eine Sicherheitsmaßname, damit die Struktur nur mit nullen initialisiert wird und nicht irgendwelche zufällige Werte hat. Das ich aber auch nie auf die Idee gekommen bin, das dazuzuschreiben, so wie es in den meisten Tutorials steht http://www.c-plusplus.net/ubb/ubb/rolleyes.gif ...

Bei der ganzen Sache gibt es nur noch ein Problem: Die Farbzuweisung!!! Ich rechne das mit folgendem Makro:
#define rgb(r,g,b) = b|(g<<5)|(r<<11), wobei r, g und b für rot grün und blau stehen.
Wenn ich jetzt "reine" Farben (also rot[255,0,0], grün[0,255,0], blau[0,0,255] oder weiß[255,255,255]) nehme, dann funzt das. Wenn ich allerdings z.B. hellgelb[255,255,100] nehme, dann bekomme ich ganz seltsame Farben, woran liegt das???

PS: dieses Vram[x+yZeilenBreite]* muss bei mir (800x600x16) so heißen, damit es funzt: Vram[x+yZeilenBreite/2]*

------------------
Mfg, D@nm@n

Crax

Hallo,

ZeroMemory: siehe hierzu http://www.c-plusplus.net/ubb/ubb/Forum7/HTML/000688.html
http://www.c-plusplus.net/ubb/ubb/wink.gif

CU

D*nm*n

Genau daher hab' ich's doch http://www.c-plusplus.net/ubb/ubb/biggrin.gif http://www.c-plusplus.net/ubb/ubb/biggrin.gif http://www.c-plusplus.net/ubb/ubb/biggrin.gif !!!

------------------
Mfg, D@nm@n

TGGC

Code:

convertRGBToColorModel(WORD wRed,

                                   WORD    wGreen,

                                   WORD    wBlue)

{

DWORD    dwRed;

DWORD    dwGreen;

DWORD    dwBlue;

WORD    wBits;

DWORD    dwMask;



// Rot

wBits=1;

dwMask    = dwMaskRed;



while (dwMask=dwMask>>1)

{

    wBits++;

}

dwRed    = DWORD (wRed) << wBits;



// Gruen

wBits    = 1;

dwMask    = dwMaskGreen;



while (dwMask=dwMask>>1)

{

    wBits++;

}

dwGreen    = DWORD (wGreen) << wBits;



// Blau

wBits    = 1;

dwMask    = dwMaskBlue;



while (dwMask=dwMask>>1)

{

    wBits++;

}

dwBlue    = DWORD (wBlue) << wBits;



return (((dwRed>>8)&dwMaskRed) |

        ((dwGreen>>8)&dwMaskGreen) |

        ((dwBlue>>8)&dwMaskBlue));

}

[/code]

die Masken bekommt man mit irgenwelchen DX-fkts, schau mal in die Doku...

D*nm*n

Danke http://www.c-plusplus.net/ubb/ubb/smile.gif, nur geht das nicht einfacher (= ohne eigene Fkt), zum Beispiel mit einem Makro?

------------------
Mfg, D@nm@n

Ignaz Rutter

Du kannst auch Dein Makro weiterverwenden, nur solltet Du beachten, daß in einem 16 Bit Farbmodus nicht für jeden Farbanteil 256 Abstufungen(8 Bit) existieren. Du solltest Dich einfach auf die Bereiche von 0 bis 31 bzw. bei 565 auf 0 bis 31, 0 bis 63, 0 bis 31 beschränken.

Oder Du schreibst Dir noch eine Funktion die's umrechnet... Aber di hatten wir ja schon!

CU

TGGC

Zitat:

Original erstellt von D@nm@n:
**Danke http://www.c-plusplus.net/ubb/ubb/smile.gif, nur geht das nicht einfacher (= ohne eigene Fkt), zum Beispiel mit einem Makro?

**

weiss nich, obs einfacher geht, ich weiss nur, das ich das Teil so geschreiben hab, das es in allen Farbmodi funzt...

Christoph

Also ich find Makros NICHT einfacher als Funktionen! Du hast NULL Typsicherheit und debuggen kannst du's nur extrem schwer!

D*nm*n

Tja, das ist deine Meinung! Ich hab' zwischenzeitlich in jedem Fall ein vollständig funzendes Makro gefunden! Das sieht so aus:

#define rgb(r,g,b) (((r>>3)<<11)+((g>>2)<<5)+(b>>3))

Hier nochmal meine Fkt. (für alle die's interessiert):

Code:

WORD *buffer;

DDSURFACEDESC ddsd;

ZeroMemory(&ddsd,sizeof(ddsd));

ddsd.dwSize = sizeof(ddsd);

if (lpDDSurface->Lock(NULL,&ddsd,DDLOCK_SURFACEMEMORYPTR|DDLOCK_WAIT,NULL) == DD_OK)

{

buffer = (WORD*)ddsd.lpSurface;

buffer[x+y*ddsd.lPitch/2] = rgb(r,g,b);

(WORD*)ddsd.lpSurface = buffer;

lpDDSurface->Unlock(NULL);

}[/code]

------------------
Mfg, D@nm@n

Warum funzt Pixelputten mit Surface-&gt;Lock nicht???

Warum funzt Pixelputten mit Surface->Lock nicht???