Jump to content
  • Advertisement
Sign in to follow this  
SpreeTree

CreateTexture and latop issues (DX9)

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

I have a laptop with a very poor graphics card in (Intel(R) 82852/82855 GM/GME Graphics Controller) and I am having trouble with CreateTexture. If i pass in D3DUSAGE_DYNAMIC as the usage flag, the function fails. Fair enough. But if I remove it, the texture is created, but then I am unable to lock the texture and actually pass in the image data to the texture surface. The actual parameters are:
CreateTexture(256, 256,               // Height, Width
              1,                      // Mip Maps
              0 or D3DUSAGE_DYNAMIC,  // Usage flag
              D3DFMT_A4R4G4B4,        // Format
              D3DPOOL_DEFAULT,        // Pool
              &texture,               // Texture
              NULL);
Has anyone expereinced this in the past and how did you solve it? Im at work at the mo so I cant really try it out, but would it be caused by the alpha channel request? How can i pass in image data without using the DYNAMIC flag? Thanks Spree

Share this post


Link to post
Share on other sites
Advertisement
From the sounds of it your graphics card just doesn't support lockable textures. Instead use D3DXCreateTextureFromFile to load in pre drawn images in either bmp, dds, dib, jpg, png, or tga formats.

Share this post


Link to post
Share on other sites
I would create separate sysmem and vidmem textures (D3DPOOL_SYSTEMMEMORY and D3DPOOL_DEFAULT respectively). Then, after manipulating the sysmem one, send it to the video memory by calling UpdateTexture. Do note that managed resources should do this automatically.

While all cards capable of texturing are able to handle UpdateTexture, the format restrictions limit which types of textures you can create at all.

Have you tried the DX debug runtimes? The error should be very clear using that. In addition, the caps viewer utility is very nice for determining your current hardware capabilities.

Share this post


Link to post
Share on other sites
It does look like my card is just unable to handle dynamic textures. It works fine if i remove the dynamic flag and use managed textures, which for now is fine in most cases.

It may be an issue later on... but hopefully not for a while now. As for creating both system and default textures, is this not a slower method than using just managed textures, and a waste of system resources to start with?

Spree

Share this post


Link to post
Share on other sites
Quote:
Original post by SpreeTree
As for creating both system and default textures, is this not a slower method than using just managed textures, and a waste of system resources to start with?


Managed resources are merely an automated way of doing the sysmem-vidmem paging - it's not any slower nor memory-intensive either way. However, managed resources are also priority-controlled by the d3d runtime; this is of much additional value, if your program uses many textures.

Share this post


Link to post
Share on other sites
D3DUSAGE_DYNAMIC textures are textures which you will be locking **regularly**, such as once every frame or every few frames.

D3DUSAGE_DYNAMIC is a hint to the driver that **regular** locks and CPU access will be taking place on that texture. Based on this hint the driver will do thing such as place the texture in AGP memory, set up pools of discardable duplicates of the texture for renaming/multibuffering etc.

Some hardware isn't so suitable for dynamic textures and some drivers don't allow the hint flag for various reasons.

If you only need to lock and fill the texture once, you shouldn't be using dynamic textures - even if the driver supports them - their performance isn't as good as non-static textures due amongst other things to the memory differences.


So how do you fill your texture when your application starts?

1) create the texture using D3DPOOL_MANAGED. There are a number of benefits to using managed textures:

a. You can Lock() the texture to fill in the data when your application starts.

b. The D3D resource manager is actually very good and automatically handles the more unusual cases such as UMA boards and virtual texturing so you don't need to. Additionally you can control the management behaviours such as changing the priority of textures you _know_ should be left in video memory.

c. Since there's always a system memory copy of a managed resource, your lost-device handling is made vastly simpler!
[If the system memory copy isn't used in a long time, it'll be paged out, so no need to be concerned about RAM usage with managed resources]


2) Use a system memory pool and UpdateTexture() as suggested.
If you have more texture than video memory supports or come to handle things such as lost devices, then you'll need to do all the hard work yourself rather than having D3D do it (the main difference between this method and using D3DPOOL_MANAGED).

[Edited by - S1CA on September 29, 2004 9:26:28 AM]

Share this post


Link to post
Share on other sites
Thanks for the clear up.

Texturing is an area I have tended to stay away from (I had the attitude "Its showing a texture... Its good enough), so it not something I know much about so thanks for the quick replies.

Im gonna set up the textures as managed, though I have already done all the lost device handling, so I guess that wont be simplier in my case ;)

Thanks again
Spree

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!