Jump to content
  • Advertisement
Sign in to follow this  
dpro

Issues with D3DXCreateTextureFromFileInMemory

This topic is 4864 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

Now I may be way off base here, but is there a reason why I cannot do this? I have the bits from a bitmap, everything relevant to it in fact, then I create a CBitmap object (MFC of course), and then I pass it to D3DXCreateTextureFromFileInMemory. I am wondering if I can... 1.) Do this or 2.) If so, why does it tell me unsupported file format? (Followed by : (hr=D3DXERR_INVALIDDATA (0x88760b59)) ) or 3.) If neither work, is there a good alternative to copying a randomly changing bitmap to a texture to display. I tried using surfaces but I was told a texture would be better overall for my needs. So here I am wondering what would be the best way to copy the bits into a texture. I would prefer a d3dx solution, but so far that has failed. I thought I could do texture->LockRect and then copy the bits over, but I am thinking I would need to bitblt them onto a level surface of the texture, or am I still off base? Thanks in advance! :)

Share this post


Link to post
Share on other sites
Advertisement
If you've already got the bits from the .bmp file in memory somewhere, then I don't think you need to create the CBitmap object. You should be able to just pass a pointer to the raw bitmap data in memory to D3DXCreateTextureFromFileInMemory.

Remember that a .bmp file has a header struct as well as the actual texel values and if you're going to use D3DXCreateTextureFromFileInMemory, your pointer needs to point to that header part of the .bmp data. If you just have the raw texel data, then using LockRect and copying the data would be better.

neneboricua

Share this post


Link to post
Share on other sites
Hmm yes I do have the bits, but no "true" header. I have most of the header info, but I am never given a bitmap to load/or a bitmap preloaded. All the data is taken from a camera and fed to me.

So you would recommend then a lockrect and then a quick memcpy of the bits I have to the texture and then unlocking? I tried it earlier but it was not working right, however it could have been a memory issue.

I figured I could do something like this because I was able to use d3dxLoadsurfacefrommemory just fine, though, it was very slow. Anyway, thank you again for the help!

Share this post


Link to post
Share on other sites
Quote:
Original post by dpro
So you would recommend then a lockrect and then a quick memcpy of the bits I have to the texture and then unlocking? I tried it earlier but it was not working right, however it could have been a memory issue.

I would say a doing a Lock is the way to go. But remember that you can't just do a straight memcpy to the texture because often times, the pitch of the texture is not the same as its width. The pitch is the number of bytes in one row of the texture. The graphics card driver may place your texture in a block of memory bigger than what you really asked for.

For example, say you create a texture that is 200x200. The driver may decide that it will create your texture in a block of 256x200 for alignment reasons. So in this case, the Pitch of your texture would be

256 pixels * 4 components/pixel * 4 bytes/component = 4096 bytes.

Your texture will still only use 200x200 texels but this means that a straight memcpy won't work. You'll have to do a double-for loop and account for the pitch of the texture.

neneboricua

Share this post


Link to post
Share on other sites
Hmmm interesting, so a texture with a single byte describing each pixel would be for a 1024x768 texture (or more likely 1024x1024) would be 1024 then since 1 byte/component * 1 component/pixel?

How would you get the correct size info from D3D when you create the texture? Whats happening now is I call D3DCreateTexture with a width/height that I want with the format D3DFMT_A8R8G8B8, so I am assuming the pitch then actually be 4096 due to 4components/pix and 4bytes/component?

So after that, I am unsure how to actually write that to the texture, can I simply do LockRect then get the DC and bitblt it? Or how would I access that? Or can I simply do this?

 if ( SUCCEEDED( texture->LockRect( 0, &d3dlrect, NULL, D3DLOCK_DISCARD )))
{
UCHAR bytes[] = new UCHAR[sizeof(UCHAR) * 4096 * 4096];
for(int j = 0; j < 4096; j++)
{
for( int i = 0; i < 4096; i++)
{
int index = (j * i) + j;
bytes[ index ] = ( some UCHAR value);
}
}
texture->UnlockRect( 0 );
}


I am not sure if the math is all correct, but is the form at least kind of correct? Maybe I am just too tired to see it, but it would seem to me that something like that would work. Thanks again.

Share this post


Link to post
Share on other sites
You can't just create some memory somewhere and write to it. You need to write to the actual texture. After the LockRect call, d3dlrect.pBits contains a pointer to the texture data and d3dlrect.Pitch contains the pitch.

Share this post


Link to post
Share on other sites
You could just grab the primary surface of the texture (GetSurfaceLevel(0, &pSurface)), and then use D3DXLoadSurfaceFromMemory() to copy the bits to the surface. Then release the surface of course. Additionally, you can call GenerateMipSubLevels() on the texture if you have mipmap surfaces.

Share this post


Link to post
Share on other sites
Ahh yes... I totally forgot about pBits :( a little too focused on other issues. Thanks to all who posted :) I will give this a try and will update this. Again, many thanks to all who contributed! :)

EDIT: Update, worked great! I used the second suggestion, but the first one I tried as well, thanks both of you for the ideas! :)

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!