DInput (keyboard etc...) must be acquired again because it lost focus. As for the crash when quitting, is hard to say. Are you releasing everything in reverse order? Are you releasing everything?
Like so:
if(d3dxthing)
{
d3dxthing->Release();
d3dxthing = NULL;
}
Alt tabbing in and out of a DX windows game
Author
DInput is working just fine cause it handles lost focus anyway. I also tried destructing the dinput class and reconstructing which proved useless.
It should quit the game normally. When I don't use alt tabbing it does quit normally but if I do, it doesn't. Although it seems it executes every line which it does normally.
The thing is that now when I press esc or whatever it will handle it like it was a windowed window with weird controls, for example esc brings me back to desktop without quitting the game. :O I tried to redisable the window on resetting focus but it made no difference.
It should quit the game normally. When I don't use alt tabbing it does quit normally but if I do, it doesn't. Although it seems it executes every line which it does normally.
The thing is that now when I press esc or whatever it will handle it like it was a windowed window with weird controls, for example esc brings me back to desktop without quitting the game. :O I tried to redisable the window on resetting focus but it made no difference.
Hard to say what is causing your problem. Do you know where in your app it crashes when quitting?
Author
if any of the destructors is causing this it would propably be the graphics class destructor:
The profiler tells me that it executed the lines successfully though, so I dunno.
I think that the weird window behaviour causes this instead of any destructor codes though. So you never do anything like executing the showwindow function or whatever after gaining focus?
for(int i = 0; i < 12; ++i) if(font) delete font;if(lpdevice) { lpdevice->Release(); lpdevice = NULL; }for(int i = 0; i < MAX_TEXTURES; ++i) if(texturelist) texturelist->Release();The profiler tells me that it executed the lines successfully though, so I dunno.
I think that the weird window behaviour causes this instead of any destructor codes though. So you never do anything like executing the showwindow function or whatever after gaining focus?
It looks like you're releasing your textures last. Instead, you should probably release your device last. I'm not sure if this is your problem or not, but it can't hurt :)
-John
-John
Quote:Original post by Tertsi
Well reloading ALL of the textures would not be an option, as they take a couple of seconds to reload, and sounds take another few seconds, which would make the switching back to the game take nearly 10 secs. Also all the stuff that I'd have to do is not worth while to simply have the support for alt tabbing.
So I guess I'll just ignore the alt + tab message then.
You mean it's better to prevent the player from alt-tabbing, than allowing him to do so, but taking ~10 seconds afterwards to reload everything? I think most people playing your game would disagree... :)
Quote:Original post by Tertsi
if any of the destructors is causing this it would propably be the graphics class destructor:
*** Source Snippet Removed ***
The profiler tells me that it executed the lines successfully though, so I dunno.
I think that the weird window behaviour causes this instead of any destructor codes though. So you never do anything like executing the showwindow function or whatever after gaining focus?
You should release:
buffers
textures
fonts
etc...
device (IDirect3DDevice9)
interface (IDirect3D9)
in that order
Author
Didn't do any good, anyone have any idea about the windows input problem? Cause that's obviously what's causing the hazzle.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
