Advertisement

direct draw crash

Started by September 13, 2000 10:50 AM
10 comments, last by T-dawg 24 years, 3 months ago
you have probably seen me gripe about this before but i''ll do it again because i need help. I''m trying to make a DirectDraw app (using VC++ 6) to plot pixels in a 640x480x8 mode. Creating the surface and color palette go smoothly. The problem is when I try to write to the memory/draw on the surface. During my main event loop, after I lock the surface, I make the following aliases: int mempitch = (int)ddsd.lPitch; // holder for the pitch UCHAR *video_buffer = (UCHAR *)ddsd.lpSurface; // pointer to the surface Then, I pick a color and location: UCHAR color = rand()%256; // UCHAR == BYTE int x = rand()%640; int y = rand()%480; Here''s where I think I have problems. I''ll plot a pixel like so: video_buffer[x+y*mempitch] = color; The compile, build, and run are ok, but when I exit, it causes a crash. What could be happening? "When your life reaches zero, the game is over. There are no continues, my friend." -Revolver Ocelot, Metal Gear Solid
"When your life reaches zero, the game is over. There are no continues, my friend." -Revolver Ocelot, Metal Gear Solid
Are you unlocking the surface afterwards?
Advertisement
I do unlock the surface right after I draw. Sometimes it runs ok but otherwise crashes.
"When your life reaches zero, the game is over. There are no continues, my friend." -Revolver Ocelot, Metal Gear Solid
i dont think you should be using mempitch as an int and then casting ddsd.lPitch to int

try.. (searches through old code)

hmm yes use an int, but bit shift ddsd.lPitch one to the right..
i.e.

int mempitch = ddsd.lPitch >> 1;

try that
The problem occurs when I write to the surface. The locking and unlocking are ok. I get memory access violations and "write" errors. is there another way to write to the surface?
"When your life reaches zero, the game is over. There are no continues, my friend." -Revolver Ocelot, Metal Gear Solid
quote: Original post by T-dawg

The problem occurs when I write to the surface. The locking and unlocking are ok. I get memory access violations and "write" errors. is there another way to write to the surface?


Hi all.

The only thing that I can think of is that you may not be checking the return code from the surface locking function. If this is the case, you will be trying to write to an invalid address if the surface locking function fails.

Aboput other ways to write to the surface, you can use the surface's blit functions or regular GDI drawing functions. (Except for getting and releasing the DC handle, you need to use the surface's functions "IDirectDrawSurface:GetDC" and "IDirectDrawSurface:ReleaseDC", not the ones provided by GDI)

Topgoro


;You are not a real programmer until you start all your sentences with a semicolon

Edited by - Topgoro on September 14, 2000 12:30:49 PM
We emphasize "gotoless" programming in this company, so constructs like "goto hell" are strictly forbidden.
Advertisement
Argh, I need a notebook computer, never have access to my code when I need it.

This may be a stupid question. Are you filling the ddsd immediately before you use it? Microsoft claims that memory might be moved around and to always update the video memory pointer. Think you can get it from the lock function ..? , but isn''t there a GetDDSD or some such? Been too long since I used it...



____________________________________________________

"Two wrongs do not make a right; it usually takes 3 or more."

____________________________________________________
"Two wrongs do not make a right; it usually takes 3 or more."
Some mistakes are too much fun to only make once.
Never anger a dragon, for you are crunchy and you go well with brie.

quote: Original post by Ratheous

Argh, I need a notebook computer, never have access to my code when I need it.

This may be a stupid question. Are you filling the ddsd immediately before you use it? Microsoft claims that memory might be moved around and to always update the video memory pointer. Think you can get it from the lock function ..? , but isn''t there a GetDDSD or some such? Been too long since I used it...


Hi.

Actually, the only parameter that you need to initialize in the surface descriptor is the "size" member. Everything else is filled out for you by the Lock method. In fact, in the "Inside DirectX" book the author does not even clear the structure to zero before calling the Lock method. To be safe, at least initialize the "size" member.

Topgoro


;You are not a real programmer until you start all your sentences with a semicolon
We emphasize "gotoless" programming in this company, so constructs like "goto hell" are strictly forbidden.
hmm
make sure you use the flag DDLOCK_SURFACEMEMORYPTR i think it is..
so ddsd.lPitch actually contains a pointer to the locked surface
and do what i said in my previous post..
change int mempitch =..
to int mempitch = ddsd.lPitch >> 1;
quote: Original post by Quantum

hmm
make sure you use the flag DDLOCK_SURFACEMEMORYPTR i think it is..
so ddsd.lPitch actually contains a pointer to the locked surface
and do what i said in my previous post..
change int mempitch =..
to int mempitch = ddsd.lPitch >> 1;


Hello all.

First I need to clarify that the DDLOCK_SURFACEMEMORYPTR does not do a thing. If you check ddraw.h you will see that it is declared with the value of 0 (zero). Think about it, if you don''t need that pointer to the surface memory, what are you calling the lock method for?

Second, Quamtum, that right shifting (efectively an integer division by 2) must be something specific to that old application you wrote, because that is, I am afraid, an otherwise incorrect thing to do.

Let''s say that we have a 640 x 480 x 8 display mode. If the pitch is 640, then the "int mempitch = ddsd.lPitch >> 1;" statement will use 320 instead of 640, the latter being the correct value you need to add to the surface pointer in order to cause it to point to the same pixel column in next row.

Even if your old application used a 16 bit mode I still don''t see how dividing the pitch by 2 would be helpful, exept to determine an addup value to move the pointer to the middle of the screen or something. And even then the DirectX documentation does not recoment using the pitch value for that.

Topgoro


;You are not a real programmer until you start all your sentences with a semicolon
We emphasize "gotoless" programming in this company, so constructs like "goto hell" are strictly forbidden.

This topic is closed to new replies.

Advertisement