![]() |
|
cleaning up allegro at exit |
cwl157
Member #11,639
January 2010
|
I am currently writing a vertical scrolling game in allegro using Visual Studio 2008. The map i use for the game is a tile map made with mappy. Everything works except i have a problem. Sometimes, especially after the game has been open for a while, when i exit the game, it doesn't close all the way. The game window dissapears but the game is still in the taskbar and the application and process are still in the task manager. the only way to close the application is from the task manager. If i right click on the game in the task bar and say maximize it just comes up with a blank black window with a title bar. I also noticed in task manager there are only 2 threads when there are usually 4 and the game when running takes up about 13,000K of memory but when its in this closed but not closed state it only takes up between 1,000K and 2,000 K of memory and only have 2 threads running. So its like something isn't cleaning up right when the application is quit. I am running windows 7 x64 as my test environment but i've made 3 other similar games on this and have not had problems with those so i don't think its the environment. It looks like its not cleaning up the screen or something. Anyone have any ideas? Thanks. |
Arthur Kalliokoski
Second in Command
February 2005
![]() |
How do you close it? Clicking on the X at the upper right corner of window? That causes problems sometimes, there's some callback or something to handle it. “Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.” ― Robert A. Heinlein |
cwl157
Member #11,639
January 2010
|
I just use the ESC key like the other 3 programs i've done. The main game loop goes until the ESC key is pressed then the cleanup is called and main returns. |
Arthur Kalliokoski
Second in Command
February 2005
![]() |
There's always the possibility of running it in the debugger, although it might not show the problem then (different initializations etc.) “Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.” ― Robert A. Heinlein |
cwl157
Member #11,639
January 2010
|
Thanks for the feedback. When you mentioned different initializations i looked at my init function for this game to see if it was different from the others and the only difference is in this game i called install_timer before install_keyboard. So i flipped those so i call install_keyboard first and then install_timer just like my other programs. The initial tests are good. I'll post back here after i test it some more and leave it running for longer time periods. Thanks. |
Arthur Kalliokoski
Second in Command
February 2005
![]() |
I meant the debugger and debug mode initialize things differently, clearing new[] memory etc. “Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.” ― Robert A. Heinlein |
torhu
Member #2,727
September 2002
![]() |
Sounds a bit like the issue I'm having, which might be related to running on a dual core. |
cwl157
Member #11,639
January 2010
|
Yea it does seem to be like that issue. Well, after some more tests it seems like calling install_keyboard and then install_timer fixed it. Weird that the order would make a difference though. |
bamccaig
Member #7,536
July 2006
![]() |
I notice that in torhu's code from the other thread there is almost no error checking regarding Allegro's initialization (I only bothered looking in main.c because the project looks pretty big). That might be something to concern yourself with. If something non-vital failed to initialize properly, the program might appear to run right, but might have some consequences later on. Also, it could just be memory corruption that happens to correct itself by chance when you rearrange function calls. If it was Allegro 4.2.2, I assume it would have been detected by now (though I suppose it's possible that we all just learned to install the keyboard first... Setting your own atexit that doesn't account for the Allegro cleanup might also cause problems as Allegro spawns its own threads for some things and I assume that these need to be cleaned up before the process will die. If you are going to use your own atexit then you can use install_allegro instead of allegro_init (or call allegro_exit manually). -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) |
|