Thread: Access Violation Of Memory Buffer WHY??

Perhaps the buffer is not lockable. If this is the back buffer then you must set correct flags for the buffer to be locked. Otherwise Lock() is guaranteed to fail.

Also most surfaces are not lockable. The whole premise behind Direct3D is to eliminate direct accesses to the buffer. Basically you would use DrawPrimitive() to render textures instead of rendering yourself. Also the texture stages are used to do multi-texturing and other effects, but notice you never really get to physically 'touch' the surface in your code.

I've also done some assembly programming with DirectX buffers and I can tell you that they are not as they appear. For instance:

Code:

...
bufferoffet=0;
for (int i=0;i<height;i++)
{
Buffer.ptrBuffer[bufferoffset]=color_value;
bufferoffset+=Buffer.Pitch;
}
...

This works in C/C++ but not in assembly, barring the Buffer structure here in assembly. Assume that ptrBuffer is a pointer to a valid Direct3D buffer that has been locked.

Code:

...
START:
mov edi,ptrBuffer
xor	edx,edx
 
RENDER: 
mov eax,colorvalue
stosd
;account for DWORD we just wrote
sub edi,4
 
;move down one line
add edi,BufferPitch
 
;increment height counter
inc edx
 
;test for end of loop condition
cmp edx,0
 
;if edx!=0 (ZF=0) then short jump to RENDER label
jne RENDER
...
...

But this does not work. You will get several small images if you do this. My assumption was since you are using Buffer.Pitch or BufferPitch as the width of the buffer then it must already be shifted left by the correct value to account for writing DWORDs and not BYTEs. However, this is not the case. In order for the code to work, barring any other errors, you must

Code:

...
;use ebx which hasn't been used yet
mov ebx,BufferPitch
 
;multiply by 4 -> hence 4 bytes per DWORD..BufferPitch doesn't account for this?????
shl	 ebx,2
add	edi,ebx
..

But if you multiply BufferPitch by 4 in C you will get a very nast mess on screen and more than likely crash hard.

>>the if statement right at the beginning of the code should catch it and then the loop should be broken

Well, the way your message loop is set up, the DirectDraw code will still get executed after each message is processed - meaning that even if WM_QUIT is posted from WM_DESTROY, the DirectDraw code will be executed at least once before the WM_QUIT is received, depending on how many messages are waiting in line before the WM_QUIT. To (partially?) fix that (so that all currently queued messages will be handled before the DirectDraw code is executed), you can put all the DirectDraw code in an else{} block after the if(PeekMessage()), like I mentioned above. I'm not totally sure if the WM_QUIT will be guaranteed to appear in the message queue exactly when you call PostQuitMessage() though, since I'm not familiar with the internal workings of the Windows messaging functions. You'll have to ask the gurus here about that

**EDIT**
>>Lock() is guaranteed to fail.
In which case, the program would crash on startup as opposed to exit, like I mentioned before

>>The whole premise behind Direct3D
Again, this is DirectDraw... Remember 'lpddsPrimary'? => 'Long Pointer to DirectDraw Surface Primary'

Originally Posted by Bubba

Yep, I knew that looked suspicious and almost posted that was the problem. Salem is correct, you are destroying the pointer to your surface therefore it is NULL when you attempt to write to it. Very bad thing.

No, that variable can and should be zeroed out because it only recieves information about the surface from the Lock function.

Originally Posted by Bubba

Also most surfaces are not lockable.

This is not Direct3D, it's DirectDraw.

Originally Posted by Hunter2

Well, the way your message loop is set up, the DirectDraw code will still get executed after each message is processed - meaning that even if WM_QUIT is posted from WM_DESTROY

You are correct. Simply adding a test condition for Lock will solve the problem.

Oh right. When DestroyWindow gets called, the window gets destroyed (... yes, duh lol). If the surface has any association with the window at all (i.e. a clipper, perhaps) it is probable that you will be unable to draw to it anymore, thus causing Lock() to fail.

bartybasher, are you using DestroyWindow() to shutdown your application, or is it called somewhere along the line? If it is, try rearranging your shutdown sequence in some way so that it gets called after all the directdraw is cleaned up. I think this is the same problem that I had a while back.

No, that variable can and should be zeroed out because it only recieves information about the surface from the Lock function.

Yes I was thinking of something else when I wrote that. I do not use DirectDraw anymore rather I render directly into the swap chain in Direct3D if I'm doing direct buffer access programming.



Using DirectDraw interfaces is deprecated and should not be relied upon even though technically they are still there. Direct3D provides a much better way of accessing the hardware buffers.

DirectDraw is no more. They are both merge into DirectGraphics. I would not touch DirectDraw since the same functionality can be gained from Direct3D.

And no...all surfaces are not lockable at all times. Locking numerous surfaces causes sever performance issues and it also looks as though you are writing directly to the primary buffer which is not good. You should be writing to the secondary buffer then when it flips it will display the secondary on the primary and/or flip it depending on your mechanism.

So even though you fixed that problem...you still are going to run into several others if you insist on using DirectDraw instead of Direct3D.