Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I wanted to switch to IDirect3DDevice9Ex, purely for the SetFrameLatency function, as fullscreen vsynced D3D seemed to produce noticable input lag.

But then it tells me 'ha ha ha! now you can't use D3DPOOL_MANAGED!':

Direct3D9: (ERROR) :D3DPOOL_MANAGED is not valid with IDirect3DDevice9Ex

Is this really as unpleasant as it looks (when you're relying quite heavily on managed resources) - or is there a simple solution?

If it really does mean manual management of everything (reloading all static textures, VBs, and IBs on a device reset), is it worth the hassle, will IDirect3DDevice9Ex bring enough benefit to make it worth writing a new resource manager?

Starting to think I must be doing something wrong, due to this:

Direct3D9: (ERROR) :Lock is not supported for textures allocated with POOL_DEFAULT unless they are marked D3DUSAGE_DYNAMIC.

So if I put my (static) textures in POOL_DEFAULT, they need flagging as D3DUSAGE_DYNAMIC, just because I lock them once to load the data in?

share|improve this question
Were you able to solve this? I'd sure like to see an accepted answer, or at least your own solution to the problem, as I am running into the same issue. – Jonathan Mee Dec 30 '13 at 13:17

This doesn't completely solve your problem but in DirectX 9EX device loss only happens the same times it does in D3D11 (GPU driver changes, PC sleeps, etc..).

This means you don't need to worry about reloading your resources unless you wan't to support those cases. I think that's why they removed D3DPOOL_MANAGED since it would be basically the same as D3DPOOL_DEFAULT


share|improve this answer
Oops, sorry. Got tricked by Mark's comment and performed thread necromancy :) – Lucas Oct 19 '11 at 22:24
Yea but, grrrreeaaat answer! (if this is in fact true) – bobobobo Oct 20 '11 at 1:27

There is no simple solution I am aware of, you'll have to transition your resources to another pool type. I haven't ever really noticed the input latency issues you're describing, so I would venture to guess that they might be caused by a bug elsewhere in your code. Can you verify that it's a D3D-related issue (maybe it's a driver/card problem?) Or at least provide a more in-depth description of the problem?

My hunch is that it's not worth the effort to transition to D3D9Ex just for that method.

share|improve this answer

I ran into this exact issue. In our app, the user can change any texture at any time, so we need them to be dynamic. I now create D3DUSAGE_DYNAMIC D3DPOOL_SYSTEMMEM textures and for each one I create a D3DPOOL_DEFAULT texture counterpart. For the D3DPOOL_DEFAULT textures I have a flag which indicates when it was last used. If I get a memory error allocating a D3DPOOL_DEFAULT texture, I find the oldest one, delete it, and try again, (until I run out of textures to free, but it never goes that far). If we try to use a freed texture, I simply re-create the D3DPOOL_DEFAULT texture from the D3DPOOL_SYSTEMMEM texture.

For you, if you never change your textures, don't try to lock them to put the initial image on there. Instead create a D3DPOOL_SYSTEMMEM texture, call UpdateTexture() to draw it onto your write-only D3DPOOL_DEFAULT texture, and then free the SYSTEMMEM texture if you wish.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.