IDirect3DTexture9
You have to get a pointer to a texture/render-target/buffer to edit it pixel-by-pixel. Say you created a 32-bit 256x256 colour texture, it would look something like this:
(might not be 100% correct)
This only works for power-of-2 textures as I left of the stuff for padding. Also be aware that if you use a 16-bit format like A1R5G5B5 then you would need an unsigned short pointer instead of unsigned int/long.
Also if you want to create images out of raw pixel data check out D3DXLoadSurfaceFromMemory().
This has been asked alot. Look through the DirectX forum some more and I'm sure you'll see more examples.
(might not be 100% correct)
LPDIRECT3DTEXTURE8 Txr;D3DLOCKED_RECT Rc;unsigned int* Pntr;D3DXCreateTexture(D3DDevice,256,256,0,0,D3DFMT_A8R8G8B8,D3DPOOL_MANAGED,&Txr)Txr->LockRect(0,&Rc,NULL,D3DLOCK_NOSYSLOCK);Pntr=(unsigned int *)Rc.pBits;Pntr[(10*256)+80]=0xFF00FF00; //plots a full green pixel at 80,10//do more drawingTxr->UnlockRect(0);
This only works for power-of-2 textures as I left of the stuff for padding. Also be aware that if you use a 16-bit format like A1R5G5B5 then you would need an unsigned short pointer instead of unsigned int/long.
Also if you want to create images out of raw pixel data check out D3DXLoadSurfaceFromMemory().
This has been asked alot. Look through the DirectX forum some more and I'm sure you'll see more examples.
Pntr=(unsigned int *)Rc.pBits; Why (unsigned int *)??
I compile succesfully, bu i get break here: Pntr[(10*256)+80]=0xFF00FF00; Whats wrong??
ryt
I compile succesfully, bu i get break here: Pntr[(10*256)+80]=0xFF00FF00; Whats wrong??
ryt
Check to make sure LockRect() returns a successful HRESULT, and also check to make sure that Rc.pBits is not NULL. The LockRect() call might have failed because the lock flags weren't valid for the texture type. Try D3DLOCK_NOSYSLOCK | D3DLOCK_DISCARD for your lock flags, instead of just D3DLOCK_NOSYSLOCK. Or look up LockRect() in the documentation to get more details.
The reason why you would use an unsigned int pointer in this case is because an unsigned int is (almost always) the same size as a D3DMT_A8R8G8B8 pixel, so casting hte Rc.pBits pointer to an unsigned int pointer is basically making it so that it can be used as if it is an array of pixels.
The reason why you would use an unsigned int pointer in this case is because an unsigned int is (almost always) the same size as a D3DMT_A8R8G8B8 pixel, so casting hte Rc.pBits pointer to an unsigned int pointer is basically making it so that it can be used as if it is an array of pixels.
In my version i put D3DPOOL_DEFAULT instead of D3DPOOL_MANAGED. Now it works, but i dont understand it, shouldnt it also work with D3DPOOL_DEFAULT??
You'll have to check the documentation for details. Get used to it, because the documentation is a great help for answering many questions more quickly and accurately than the forums often can.
The main idea behind using managed textures and locking is because a managed texture has a local (system memory) copy of the pixels as well as the actual used copy in video memory. So when you lock it, you have access to the system memory copy, and can change it, read from it, etcetera. When you unlock it, the drivers will update the video memory copy when they get a chance. With default pool textures, there isn't any managed local copy, so you have to be careful about specifying usage for the texture, and flags for locking. I use a lot of dynamic usage textures in the default pool, because they are designed for being locked often, so the drivers do things a bit differently, but a normal texture is designed to not be locked and read from or written to regularly, especially not read from. Thus UpdateTexture() and UpdateSurface() are the recommended methods in the documentation. Usually when you do need access to a texture, you only need to write to it, not read from it, since it normally hasn't changed since you last copied it into video memory.
The main idea behind using managed textures and locking is because a managed texture has a local (system memory) copy of the pixels as well as the actual used copy in video memory. So when you lock it, you have access to the system memory copy, and can change it, read from it, etcetera. When you unlock it, the drivers will update the video memory copy when they get a chance. With default pool textures, there isn't any managed local copy, so you have to be careful about specifying usage for the texture, and flags for locking. I use a lot of dynamic usage textures in the default pool, because they are designed for being locked often, so the drivers do things a bit differently, but a normal texture is designed to not be locked and read from or written to regularly, especially not read from. Thus UpdateTexture() and UpdateSurface() are the recommended methods in the documentation. Usually when you do need access to a texture, you only need to write to it, not read from it, since it normally hasn't changed since you last copied it into video memory.
From SDK:
Quote:Textures placed in the D3DPOOL_DEFAULT pool cannot be locked unless they are dynamic textures or they are private, four-character code (FOURCC), driver formats. To access unlockable textures, you must use functions such as IDirect3DDevice9::UpdateSurface, IDirect3DDevice9::UpdateTexture, IDirect3DDevice9::GetFrontBufferData, and IDirect3DDevice9::GetRenderTargetData. D3DPOOL_MANAGED is probably a better choice than D3DPOOL_DEFAULT for most applications.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement