I''ve had full version games that do the same.
Just check the task manager when you close your game and see if it is still running.


a.h{text-decoration:none;color:blue;};a.h:hover{text-decoration:underline;background:red;};

Snootchie Bootchies!

-=CF=-

This problem was discussed on this message board before -- it turned out that improper cleanup code is always to blame. (BTW, full version games that do this just fail to take the time to fix it -- production schedules are tight and it''s considered a little bug...as if there was such a thing as a little bug!) Make sure you know how Windows shut down works:

1) The main window is created.

2) DirectX is initialized, along with the program''s initialization.

3) The program enters the main message loop, getting and dispatching messages.

(The program runs for a while.)

4) The user closes the window, causing a WM_CLOSE message to be sent to your WindowProc.

5) Soon after that, you call DestroyWindow, which destroys the window and causes a WM_DESTROY message to be sent to your WindowProc.

6) Usually in either WM_CLOSE or WM_DESTROY, you call PostQuitMessage(0). This posts a WM_QUIT message to your program''s message queue.

7) When your main loop receives a WM_QUIT message, it breaks.

8) The shutdown code is executed, and DirectX is uninitialized.

9) The program exits WinMain.

Are you doing things in that order?




- null_pointer
Sabre Multimedia

This is how it works:

1. Setup window (hinst, hwnd, etc.)
2. Setup DirectX (D3DX, D3D, DDraw, DInput)
3. Message loop (If message, do message stuff, if not, do game stuff)
4. WM_CLOSE. Shutdown DX.
5. WM_DESTROY. Postquit.
6. If quit in message loop (yes), exit app.

I''m sure I read in the DDraw docs that you gotta free DDraw before you destroy the window, which means before you get the WM_DESTROY command. Isn''t that right?


- IO Fission

Tearing 'em apart for no particular reason...

This one had lots-o-replys.

In a joint programming venture where I and another programmer were using the same code all except for the main windows initilization and message handling, mine didn''t have the ''ghost'' button on the task bar but his did. We followed the code back to see what the problem is. My code returned a value all the way back to WinMain and his didn''t, that was the only difference. just make sure after you unallocate everything you return a value from winmain and you shouldn''t get that.

Oh, well. Nice idea, would''ve been good if it worked. My prog already was returning the value of msg.wparam, and i tried it a coupla different ways. Almost worked when i used a break out of the message loop instead of return, and just returned 0 at the end, but after 6 attempts the ghost appeared (scary).

- IO Fission

Tearing 'em apart for no particular reason...

That''s really strange, could be that it just works differently on different computers, or maybe you have some memory that isn''t being trashed before the window is destroyed. Oh well, that is pretty much the same thing everybody else had to say anyway.

Here''s something:

I come back to my computer after a while: Blank screen saver.
Ok, so i move the mouse to go back to the desktop, when it does there is a button in the taskbar labelled "Screensaver". Same prob. Never happened before, though. Could it be something my computer has picked up, like since updating stuff from that Windows Update site (Cause I have done that before and since it started) ?

- IO Fission

Tearing 'em apart for no particular reason...

The screen saver thing is probably caused by the same reasons given as for why programs leave the button, because screen savers are really just programs themselves.

+AA_970+

quote: screen savers are really just programs themselves.

Don't take this the wrong way, but I do alreay know that. I figure it's not my problem, cause the screensaver in question was the original blank one, comes with Win, and had never done it before. Now it does it nearly all the time. I bet it was one of those damn critical updates. I'm getting too many of those lately


- IO Fission

Tearing 'em apart for no particular reason...

Edited by - IO Fission on June 17, 2000 4:26:44 AM