Archived

This topic is now archived and is closed to further replies.

Despotismo

Cosmetical Error While Closing DirectX

Recommended Posts

Does it happens to everybody that when you finish your DirectX application, if run from the Visual Studio Interface, then it appears with the size reduced, and, if you are using any pop-up programs (ie ICQ), it also appears with the size reduced? It seems that the programs adjust their size to the DirectX resolution used in the game. Has anyone managed to solve this problem? Despotismo AKA Javier Otaegui Sabarasa Entertainment www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
Yup, happens to me too. I haven''t found a solutin for ICQ other than just putting it in the left corner intead, but you can just de-maximize the VStudio window and stretch it to full screen by hand and it works just fine^^



-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)

Share this post


Link to post
Share on other sites
That''s true, but it''s not so elegant. The problem is that when common users of the game play it, everything must be fine, and I should leave the programs in the desktop exactly as I found them.

I think that perhaps by inverting something in the closing sequence of the game, this can be worked around.

Despotismo AKA Javier Otaegui
Sabarasa Entertainment
www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
I don''t think there is any way around it, you just have to put up with it. It might help if you used IDirectDraw::RestoreDisplayMode() at the end before you released your DirectDraw object.

------------------------------
#pragma twice


sharewaregames.20m.com

Share this post


Link to post
Share on other sites
quote:
Original post by Quantum

i think the problem happens when the resolution used by the game is less than the desktop resolution


Can''t be.
I use 1024x768 all the time (On my desktop and in my apps) and it still happens.



- Goblineye Entertainment
The road to success is always under construction

Share this post


Link to post
Share on other sites
if you are using exclusive mode, you need to restore normal mode before destroying your ddraw object.

    
pDD->SetCooperativeLevel(0, NORMAL); //dunno the excact syntax



rid

Share this post


Link to post
Share on other sites
I am calling the shutdown code from the WM_CLOSE message, and I''m also using RestoreDisplayMode(), but it doesn''t seems to work. I''ve inserted the SetCooperativeLevel(hwnd,DDSCL_NORMAL) code also, but it keeps doing the same.

I think that the problem isn''t in the shutdown of the program, but, instead, it is in the initialization of DirectX. While we are in fullscreen mode, some update messages are thrown to the other apps, and they check, lets say, GetSystemMetrics() or similar, and they resize themselves. There must be some way to solve this.

Despotismo AKA Javier Otaegui
Sabarasa Entertainment
www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
I believe you can safely ignore this. I''m fairly sure that this only happens during debug runs from msvc. If you do a build, close msvc, then run the actual .exe using windows this doesn''t happen.

I''m almost certain anyway

Just because the church was wrong doesn't mean Galileo wasn't a heritic.
It just means he was a heritic who was right.

Share this post


Link to post
Share on other sites
I used to get the same problem, but it went away after I read somewhere (and implemented) that you have to completely shut down DirectDraw in a cerain order, then the problem never occurs.

Or something like that anyway.

Waassaap!!

Share this post


Link to post
Share on other sites
I have the same problem, but here''s a few notes that I managed to gather:

As furby100 mentionned, doing IDirectDraw::RestoreDisplayMode() when before shutting down DD is a good idea, but since IDirectDraw2 it is called automatically (see SDK).

Also, you must destroy DD objects in WM_DESTROY (see DirectX FAQ here).

Don''t know if you noticed, but it seems to happen only with VC++ and ICQ. These apps might be the problem, instead of DirectX.

mr_jrt seems to have solved the problem. I''ll ask him personally (unless he happens to read this thread again). I''ll make a new thread with the solution if I can get any source out of him

.(Trancelucid).

Share this post


Link to post
Share on other sites
It would be great if you post a link to the solution in this thread. Thanks.

Despotismo AKA Javier Otaegui
Sabarasa Entertainment
www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
Ok, sorry guys, I may have been a little bit presumptious with my last post. I used to get the resizing thing every time I ran my prog from the IDE, but after some code fiddling/re-arranging, it happens very, very, rarely, but it does occasionally happen to the IDE.

Sorry to get your hopes up, but it happens so rarely it had been a real long time since it last happened (when I posted) so I thought I had solved it, but alas, I hadn't. I can't post code because I'm working on a game engine (who isn't these days?) and the directdraw code is woven into it tightly, but I'll sit down with the code and try to work out the order I've got things going (which is all you need really), but I think its just a general reverse-order shutdown of everything.

In addition, check that your game loop isn't running in the last loop iteration after WM_QUIT. I found that I hadn't updated my msg. handler code for months and the WM_DESTROY message posted a quit message, instead of gracefully informing the engine to shut itself down, and letting the engine post the WM_QUIT.

Other than that, not too much I can say as I can't for the life of me remember where I read the info on this problem, but I'll rack my brains for an answer for you guys.

Once again, sorry for getting your hopes up.

[edit]
Just thought I'd add that the ICQ thing is a bug with ICQ, it happens when anything uses DirectDraw. As for Visual Stuido, that's what I meant I kinda-sorted out as I managed (somehow) to get it to hardly ever happen.
[/edit]

Waassaap!!

Edited by - mr_jrt on October 9, 2000 9:34:38 PM

Share this post


Link to post
Share on other sites
I managed to make it work, except it still "bugs" every now and then... here's what I did:

To create window:
CreateWindowEx(
WS_EX_TOPMOST,
"blah",
"blah",
WS_VISIBLE | WS_POPUP,
0, 0, 0, 0,
NULL, NULL, hInstance, NULL );


My DDraw shutdown function.. the SetCooperativeLevel seemed to make a big difference (in the number of occurances of the "bug").
if( NULL != g_pDD )
{
g_pDD->RestoreDisplayMode();
g_pDD->SetCooperativeLevel( hwnd, DDSCL_NORMAL );
if( NULL != g_pDDSBack )
{
g_pDDSBack->Release();
g_pDDSBack = NULL;
}
if( NULL != g_pDDSPrimary )
{
g_pDDSPrimary->Release();
g_pDDSPrimary = NULL;
}
g_pDD->Release();
g_pDD = NULL;
}


Also, putting the DD shutdown function in WM_CLOSE instead of WM_DESTROY seemed to help. I don't know if there's a big difference in reliability (MS suggests we put it in WM_DESTROY), but from the MSDN documentation, it seems that WM_CLOSE calls WM_DESTROY . Here's what I have:
case WM_CLOSE:
DD_Shutdown( hwnd );
break;
case WM_DESTROY:
PostQuitMessage( 0 );
break;


I'd like to know if this works (or at least, better)... maybe it's just that tonight my computer doesn't feel like bugging or something

Also, if you feel like reading source code, check out the samples that come with the SDK. They all have this bug, except for the Wormhole program. I looked at it for a while, and compared it with my program (and other SDK samples that bug), but didn't find anything of help

Anyway, it's not much of a big issue, so if this doesn't work, you should just ignore it and do what DekuTree suggested (don't maximize VC, just make it a big window).

Note that I only tested it a few times (~8-9), so I can't guarantee how reliable it is, but it seems to be fine..

Hope this helps,
.(Trancelucid).

Edited by - Trancelucid on October 9, 2000 12:05:44 AM

Share this post


Link to post
Share on other sites
Ok I figured it out awhile back. This has worked for me. (RELEASE is a normal x->Release(); x = NULL MACRO)

    
if (screen.FULLSCREEN == TRUE)
{

screen.dd7->RestoreDisplayMode();

Sleep(500);

screen.dd7->SetCooperativeLevel( screen.hwnd, DDSCL_NORMAL );

Sleep(500);

screen.dd7->FlipToGDISurface();

Sleep(500);
}

RELEASE(screen.d3d7);
RELEASE(screen.dd7);


Since I inserted this code no windows have resized. I believe I do the close window after the last Releases.

Edited by - JoeyBlow2 on October 10, 2000 10:41:00 AM

Edited by - JoeyBlow2 on October 10, 2000 10:41:52 AM

Share this post


Link to post
Share on other sites
No siree... This doesn''t work neither.
I''ve tried everything suggested in this thread so far, but the problem didn''t solve.

I liked the FlipToGDISurface() approach, I will investigate this a little more and see if I can progress.

By the way, thank you all for the answers.

Despotismo AKA Javier Otaegui
Sabarasa Entertainment
www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
The solution I posted works fine on my machine at home (thanks JoeyBlow2, the Sleep() makes it even more reliable), but for some strange reason, the same source code doesn''t work on my machine at work... If I ever figure out how to fix this on my machine at work, I''ll let you guys know.

Could it be a video card issue? I have a nVidia GTS2 card at home, and an ATI (Mach 64) at work...

.(Trancelucid).

Share this post


Link to post
Share on other sites
Judging from the above comments, I would guess this is a speed issue, as JoeyBlow2''s code works with the calls to sleep(s) , and doesn''t without.

Trancelucid, how do the overall speeds of your work/home machines compare? It may be the case that one is running too fast/slow for the procedure, alternatevly, Sleep() gives up the rest of your process''s time slice, so when we Sleep() after restoring the display mode, the IDE gets a chance to re-size itself before your program completely shuts down directdraw.

This would also explain why the re-sizing of the IDE only happens every now-and-then, as mybe in these sistuations your process wasn''t interrupted during its shutdown, whilst normally it takes so long it gets interrupted before it completes.

Whoa, that was a long theorectical explaination.

-Make sense to anyone but me?

Waassaap!!

Share this post


Link to post
Share on other sites
Just to make things clearer: it does work at home without the use of Sleep(), but sometimes it resizes (hence, the use of Sleep() makes it more reliable).

mr_jrt: I fully understand , but I don''t think it is a speed issue, because I tried doing a Sleep( 2000 ); at work, and it still resized. The prob could be in the init of DDraw though , I''ll try that tomorrow... Here are the machines'' specs:

home: AMD Athlon 800, 256mb ram
work: Intel 266, 64mb ram

They *do* differ quite alot, but 2 machines aren''t enough to say we isolated the problem :\. What are the specs on your side of things?

I thought of another thing that could be the problem (though it''d be a dumb one at that), it could be related to the project files (.dsw and his friends), since when I copied the source from home to work, I only copied the .cpp and .h files. I''ll try that tomorrow morning, and let you know.


.(Trancelucid).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I have the same Problem here ... and have tried all "solutions" posted in this Forum without success ....

Same Problem at home and at work ...

cu
DarkStar

Share this post


Link to post
Share on other sites
Hi all, I tried what I had said I would, and it has nothing to do with the project files (I would of been surprised, but we never know).

mr_jrt is right, it is a cpu speed issue. Though, I don''t exactly know where. I put Sleep( 500 ) everywhere, and it seems to work fine (tried ~10 times).

Here''s where I put the Sleep()''s...

During init:
-before *and* after DirectDrawCreateEx().
-before SetCooperativeLevel()
-before SetDisplayMode()
-before CreateSurface() and GetAttachedSurface()
-before clearing surfaces (Blt( NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx ))

During shutdown:
-before RestoreDisplayMode()
-before *and* after SetCooperativeLevel()
-after every Release()


I don''t use FlipToGDISurface() as JoeyBloe2 suggested, though I agree it is a good practice.

That''s ~10 Sleep( 500 ), aka a delay of 5 seconds total. That is, everytime you''d run your program to test/debug it, you''d waste 5 secs, which is nearly twice as much time as it takes to resize the VC window manually!! Of course, you coudl try to narrow down the number of Sleep() calls to where exactly it is needed (I used them in a paranoid kind of way). Personally, I''d rather use a non-maximized-but-big window of VC than wait ~5secs everytime. IMHO, this is a FAQ, so I''ll ask furby100 if he can add this issue to the forum FAQ (just to say that the issue is related to cpu speed or something), but first, I''d like to hear from you if it does work, before putting potentially false statements in the FAQ :-)

HTH,
.(Trancelucid).

Share this post


Link to post
Share on other sites
The best solution to this is to not even use DirectDraw''s display mode switching. It''s been known to cause other bugs, not only this one. Instead use the Windows API ChangeDisplaySettings(...) call. Windows never resise when I use it, but they used to all of time when I used the DirectDraw functions.

Share this post


Link to post
Share on other sites
Hi..... I never thought that this issue was concerning so many people.

This is what I think now. When your app resizes itself, it is touching some windows parameters about the primary displays height and width. MSVS as well as ICQ, regularly check for changes in this variables, and resize themselves correspondingly. I''m working with two monitors, and ICQ won''t work in the second one. For me it''s clear that both ICQ and MSVS do check boundaries, and act on them.

If this is the thing that happens, then there''s nothing we can do to avoid this, from the directX api point of view. We could try not to modify these "desktop size" windows parameters, and see if the problem solves. Perhaps there is some parameter in the DirectDrawCreateEx() or in the SetDisplayMode() functions.

Despotismo AKA Javier Otaegui
Sabarasa Entertainment
www.sabarasa.com.ar

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I also have the bug, whatever I do, it won''t vanish. It ALSO happens if I execute my prog from within a DOS window. Anyone noticed that?

Share this post


Link to post
Share on other sites