Surface.Lock makes no sense at least to me

What are the problems with the Surface.Lock method of the Managed implementation of DirectDraw. How shall I count the ways? 1. The indices are the wrong way around. The indices are stored (x, y) unfortunately when you map this to an array of pixels it is row by row so that the fastest moving coordinate (on the right) is the X coordinate. This means that the on a 600x800 array (actually 800x600 on the array indices) if you want to set the 10th pixel of the third row then the coordinate is not (9, 2) but (2, 409) - Remember they are all 0-based. You have to figure out the correct point to converting to a linear index 2 * 800 + 9 = 1609 and then convert to the backwards coordinates x = (int)(1609 / 600) = 2 y = 1609 % 600 = 409 The x and y here are not screen x and y but the array x and y indices. 2. It is not even this good as the X-size may be wrong if you are not using a full-sized surface as the managed wrapper does not take account of the pitch (difference between length of line in bytes and the length of a row in memory). If the length of a row is not equal to the pitch then some of your points end up mapped to the unused buffer areas on the end of the lines and you cannot write to part or all of the last line. This should not happen with most full-screen modes unfortunately if you are creating a pseudo-backbuffer for the client area of a form (which can be any size), as I was, this is often not the case (1 in 4 chance of getting it right at 16-bit for my display card). 3. Pray you are not using the original MDX but the summer refresh. If you are using the original then the returned array although it is the correct length for the number of pixels is a byte array so unless it is a palletted 8-bit surface you can only access the front part of it. At least with the summer update they made it an array of the correct type (16 or 32 bit). This Nick may be your problem. If so then definitely update. What is the solution? The people who implemented this should have assumed that if you are insane enough to lock the surface and directly write pixels then you understand the linear nature of the memory and should have simply provided a 1-dimensional array (like you get in C++). Also they should learn what the Pitch property on the SurfaceDescription means and take account of it when sizing the array (and assume that you will when using it).

the return value is an Array with 2 ranks (dimensions), when the Device is set to 32 bpp, then the elements of the Array are Int32's. you can test this by checking Array.Rank, Array.GetLength(0), first dimension, Array.GetLength(1), second the dimension. you can determine the type of the elements by casting one of them to a Type. like you i also have a problem with Surface.Lock, but in a different angle. i locked the surface to directly manipulate the pixels because i wanted to create some translucencies. my blending equation is correct, and the value retrieved and the new value stored (returned by my blending equation) are also correct. but when i blitted it to the flipping chain and flipped, it doesnt display the correct bitmap, in fact it looked like a 16-color bitmap!!! any suggestions?