Quote:Original post by schupf
So what is the sense of parameter SysMemPitch if DirectX calculates its own pitch anyway? (It seems like I could you any value)
Let's say you have a 512x512 image, but you want to create a 256x256 texture from the top left part.
The trivial option is to create a new 256x256 array, and copy your data to it. Then you'd lock the destination texture, and copy the data to it in one memcpy. The pitch would then be 256xpixelSize, but you had to copy your data once just to get it to the right size. Of course, there's a much simpler way.
If you pass a pointer to the start of the first row, and provide a pitch of 512*pixelsize, DX will automagically load just the top left part. Why? because each row is 256 pixels wide. When DX finishes reading the first row, it will skip 512*pixelSize bytes forward (the pitch you provided), landing at the start of the second row in the bigger source image.
By the time it finishes 256 rows, it would have read the entire top left corner of the source image, and copied it to the new texture.
This works great for any part of a bigger image, not just the top left. And, in fact, this is exactly why DX returns a pitch value when you map a texture. If you map just part of the texture, the pitch returned allows DX to let you modify the memory directly where it is. If DX had to return all memory in a single consecutive unit, it would have had to copy the data to a new array, give it to you, and then copy it back to the right place after an Unmap. This is clearly very wasteful, and that's what memory pitch values are for, both when you pass data to DX and when DX returns data for you.
Hope this helps.