I know theres ALOT of post here about lost devices - and i've read most of them but couldnt find the answer to this. i created a new thread for the game to separate it from the message pump as suggested in an article here (erm. not a messageboard thread) I expected it would save me from pumping in my TestCooperativeLevel loop, but then it seems like having them in separate threads is whats causing the trouble. i do get the WA_ACTIVE in the WinProc after switching back to my app, but i never got the D3DERR_DEVICENOTRESET from the TestCooperativeLevel. i tested my code in another app with the gameloop in the same thread and it worked fine... im 99% sure everything is released, but anyway that should only affect the device Reset - as far as i understand. and thats about as far as i can go since im new to both c++ and directx i guess i could just forget about multithreading but i can't believe theres no way to do it...

they are

i have winmain() winproc() msgpump() in one and all the rest is in another.

sorry i should have said that

Are you using the D3DCREATE_MULTITHREADED flag when you're creating the device?
If not, try it.
I'm not sure this will fix your problem though...

i had with no luck.

and i also pass the correct hwnd when creating the device.

I thought I read somewhere that D3D had be in the same thread as the message pump. You can push your AI, physics, etc off to another thread.

Quote:I thought I read somewhere that D3D had be in the same thread as the message pump. You can push your AI, physics, etc off to another thread.

Direct3D is supposed to be initialized and released in the main thread before and after(respectively)the message pump. But any of the other API calls may be made from any thread as long as you are using the multithreaded libraries. At least that's the way I understand it.

Quote:i do get the WA_ACTIVE in the WinProc after switching back to my app, but i never got the D3DERR_DEVICENOTRESET from the TestCooperativeLevel.

Are you sure your code is being called in the correct order? Keep in mind, unless you are using mutexes or critical sections, ANY line of code in ANY function of ANY thread can be interrupted by any other thread at ANY time.
(whole lotta anys goin' on there =)

my code is still simple and i don't think i have any use for mutex.
(thanks for pointing that out anyway, i didnt know about it)

but just in case i tried to make sure it wasnt something in my code going wrong. I removed the TestCooperativeLevel loop to handle what it does (almost) by myself;
when i lost focus i released everything (including the device) and waited to get it back then reran my Init(), creating a new device..

it worked, but crashed about 20% of the time (?!)

i know its not the good way to do it, but i think it showed the problem has to be in the TestCooperativeLevel call, which can't tell when the device is ready to be reset, right?

i used multithreading because i thought it'd be easier to manage. but now im stuck with problems WAY ahead of anything i can handle. i'd need to see the TestCooperativeLevel code and i have no idea how to do it or if its even possible.

plus the fact that the D3DCREATE_MULTITHREADED flag is said to degrade performance (and don't fix anything) scared me away from multithreading.

i'll keep a backup to be ready if someone have a solution tho
maybe theres a magical flag i forgot to set