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.