Reset can't always catch everything can it?
I do not want to test the device state before EVERY draw primitive, and there is a HUGE chance a user could alt+tab during a DrawPrimitive routine where there are a few calls to drawprimitve, thus crashing hard.
I mean I have many things set up to prevent this, like the game thread sleeps immediatly after loosing focus, or as fast as the WM_LOSTFOCUS message is processed, at that point I need to work out a way to have the thread recreate the dx object, since any threads which creates the dx com should be using it as well as resetting and unloading it. So "whatever goes on in the thread stays in the thread" to quote the obvious.
NO matter how I hard I try I can't seem to picture a way which would correctly prevent any chance of a user pressing alt+tab during a rendering routine and not having it fail...OR!!
Maybe DX9 is nicer than Dx7 and if it can't render it won't crash, it will simply return DeviceLost.
Re: Reset can't always catch everything can it?
I am pretty sure it won't crash. It has at least never done this for me. In one of my books it says what happens to Draw Primitive if you try to call it when the device is lost. but I don't have that book here, and I can't test it since I am not on a dev machine. But I am pretty sure it won't crash your machine. So one test to check if the device is lost in a GameLoop should do it.
ØØ
Re: Reset can't always catch everything can it?
How do you do that lost focus check exactly Halsafar?
Re: Reset can't always catch everything can it?
Well further studies into the way it all works proves the lost focus message is actually NOT sent when going from Fullscreen to windowed....why, because when you enter fullscreen mode the window is set to disabled (i think). I know when it returns from fullscreen mode the message WM_ACTIVATEAPP is sent.
Now this is where I catch WM_ACTIVATEAPP and reset.
Now I am having another issue though, it is unrelated and has to do with my multithreaded game loop.
See I create all the com interfaces in the gamethread and work with them in the game thread. Apparently they SHOULD be created, released and managed (reset, etc...) in the thread which has the window which recieves the messages...