Jump to content
  • Advertisement
Sign in to follow this  
binpersonal

lockedRect.Pitch problem

This topic is 3797 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Dear all, I created a 128*128 texture, then use LockRect to lock and change the data. Then use a square vertex to display the texture. However, I found the LockRect result is not a square; It seems x axis is 512 pixel, y axis is 128 pixel. When I use memcpy to set the destination position ( such as draw a line), I found x position can change from 0 to 511, while y position can only change 0 to 127. Anyone can give me some advices and ideas? Do it relates to the vertex? Thank you very much! struct Vertex { float x, y, z; float tu, tv; }; Vertex g_quadVertices[] = { {-1.0f, 1.0f, 0.0f, 0.0f,0.0f }, { 1.0f, 1.0f, 0.0f, 1.0f,0.0f }, {-1.0f,-1.0f, 0.0f, 0.0f,1.0f }, {1.0f,-1.0f, 0.0f, 1.0f,1.0f } }; D3DXCreateTexture( pd3dDevice, 128, 128, 1, D3DUSAGE_DYNAMIC, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &g_pDonutTexture ); V_RETURN(pd3dDevice->CreateVertexBuffer( 4*sizeof(Vertex), D3DUSAGE_WRITEONLY, D3DFVF_CUSTOMVERTEX, D3DPOOL_DEFAULT, &g_pVertexBuffer, NULL )); void *pVertices = NULL; g_pVertexBuffer->Lock( 0, sizeof(g_quadVertices), (void**)&pVertices, 0 ); memcpy( pVertices, g_quadVertices, sizeof(g_quadVertices) ); g_pVertexBuffer->Unlock(); When I draw a line in the texture: D3DLOCKED_RECT lockedRect; g_pDonutTexture->LockRect(0, &lockedRect, NULL, D3DLOCK_DISCARD); BYTE* pData = (BYTE*)lockedRect.pBits; CData = D3DCOLOR_ARGB(0, 0, 0, 0); for (int yposition = 0; ypositon< 64; yposition++) { memcpy(pData + lockedRect.Pitch+xposition, cData, sizeof(cData[0])); } g_pDonutTexture->UnlockRect(0); D3DXMATRIX matTrans; D3DXMatrixTranslation( &matTrans, -1.0f, 0.0f, 4.0f ); pd3dDevice->SetTransform( D3DTS_WORLD, &matTrans); pd3dDevice->SetTexture( 0, g_pDonutTexture ); pd3dDevice->SetStreamSource( 0, g_pVertexBuffer, 0, sizeof(Vertex) ); pd3dDevice->SetFVF( D3DFVF_CUSTOMVERTEX ); pd3dDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP, 0, 2 ); xposition can vary from 0-512, while yposition can only vary from 0-127

Share this post


Link to post
Share on other sites
Advertisement
> memcpy(pData + lockedRect.Pitch+xposition, cData, sizeof(cData[0]));

should, at the very least have a "* y" in there.

pData + (y * lockedRect.Pitch) + xposition

But that's not right. The address doesn't increase by 1 per pixel, it increases by whatever the pixel pitch of the format is. In your case, A8R8G8B8 has a pixel pitch of 4.

pData + (y * lockedRect.Pitch) + (xposition * 4)

When you're specifying specific formats, you can hardcode a pixel pitch like this (never hardcode the line pitch, use what D3D returns to you). There is no generic way to handle pixel pitch without having a table describing each format.

You'll notice that when taking into account that a pixel is 4 bytes wide, your x range is the expected 0..127

Share this post


Link to post
Share on other sites
Thank you,Namethatnobodyelsetook, it is a bit helpful, but still puzzled. since the address increase by pixel pitch, why there is no pixel pitch in y axis?

Also, put one line in xposition*4 ,and another on (xposition+1)*4, Isn't there gaps between those two lines? It seems the x position is a discreet number now,
only happens at 1, 4, 8, 12 etc...

Thank you very much!

Quote:
Original post by Namethatnobodyelsetook
> memcpy(pData + lockedRect.Pitch+xposition, cData, sizeof(cData[0]));

should, at the very least have a "* y" in there.

pData + (y * lockedRect.Pitch) + xposition

But that's not right. The address doesn't increase by 1 per pixel, it increases by whatever the pixel pitch of the format is. In your case, A8R8G8B8 has a pixel pitch of 4.

pData + (y * lockedRect.Pitch) + (xposition * 4)

When you're specifying specific formats, you can hardcode a pixel pitch like this (never hardcode the line pitch, use what D3D returns to you). There is no generic way to handle pixel pitch without having a table describing each format.

You'll notice that when taking into account that a pixel is 4 bytes wide, your x range is the expected 0..127


Share this post


Link to post
Share on other sites
Quote:
Original post by binpersonal
Thank you,Namethatnobodyelsetook, it is a bit helpful, but still puzzled. since the address increase by pixel pitch, why there is no pixel pitch in y axis?

Think about this for a minute. How would this work?

Memory is linear. Your image is being stored as a single linear block of memory. For example, this is what a 4x4 pixel ARGB image would be laid out in memory:

ARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGB

It's just 64 bytes in a clump. If you want to access the second pixel, you need to begin reading 4 bytes in from the start of the buffer (since the first pixel occupied 4 bytes).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!