Jump to content
  • Advertisement
Sign in to follow this  
nkshs

D3DPOOL restrictions

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

Im working on small easy to use 2D graphics lib that is using Direct3D for rendering. I use the term Image to identify surface-like objects. I use D3DPOOL_MANAGED for all Images to solve all the issues with lost devices. Users can just use Image objects to draw them to a screen (back buffer) or other Images (rendering to surface). Drawing to screen is easy. I just use defaul render target (back buffer) and draw textured quad with that Image data. Now problem arise when drawing to another Image (surface). To do that i would need to set render target to that surface. But DirectX docs say that render targets must have D3DPOOL_DEFAULT memory management. I was thinking about that kind of scenario if rendering A Image to B Image: 1. Create temp render target compatible surface C same size as B Image and set render target to C 2. Use UpdateSurface() to transfer B data to temp C surface 3. Render A Image data to temp C surface 4. Use UpdateSurface() to transfer C surface data to B surface 5. Delete temp C surface and set render target back to default (screen back buffer) ... But DirectX docs say that the source surface of UpdateSurface() must be D3DPOOL_SYSTEMMEM type! Confused... How do you do that kind of things (render to managed surface) in your code?

Share this post


Link to post
Share on other sites
Advertisement
When you think about it, typically, rendering to texture means there is little requirement for having them as a managed resources. The main advantage of a managed resource is that it does not need re-creating when the device is lost - this is useful for images loaded from files because it saves reloading, however for an image you are rendering to yourself, you're probably updating it each frame, so the managed benefit is reduced. I think the simplest way might just be to keep your render target surfaces separate from your static images, creating them in the default pool, and make sure you re-create them when the device is lost.

-Mezz

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!