Every once in a while my program freezes. It's like 1 out of every five times I run it. I finally caught it in debug mode and tried to see if it was caught in some kind of infinite loop somewhere. However, it turned out that it was never going to my update section.
I think (could be wrong), that the function that updates my "system_timer" variable, for some reason, stops getting called. Here's what I think are the relevant bits of code:
| 1 | void timer1(void) |
| 2 | { |
| 3 | system_time++; |
| 4 | }END_OF_FUNCTION(timer1); |
| 5 | |
| 6 | void frametimer(void) |
| 7 | { |
| 8 | framerate = draw_ticks; |
| 9 | draw_ticks = 0; |
| 10 | }END_OF_FUNCTION(frametimer); |
| 11 | |
| 12 | void GAME::init() |
| 13 | { |
| 14 | // code clipped |
| 15 | |
| 16 | // Install Time Handler |
| 17 | LOCK_VARIABLE(system_time); |
| 18 | LOCK_VARIABLE(ticks); |
| 19 | LOCK_VARIABLE(framerate); |
| 20 | LOCK_VARIABLE(draw_ticks); |
| 21 | LOCK_FUNCTION(timer1); |
| 22 | LOCK_FUNCTION(frametimer); |
| 23 | iTimer_Speed = this->configuration->clock_speed; |
| 24 | install_int_ex(timer1, BPS_TO_TIMER(iTimer_Speed)); |
| 25 | install_int_ex(frametimer, BPS_TO_TIMER(1)); |
| 26 | |
| 27 | // code clipped |
| 28 | } |
| 29 | |
| 30 | void GAME::play() |
| 31 | { |
| 32 | // code clipped |
| 33 | |
| 34 | while(!key[KEY_ESC] && !quit) |
| 35 | { |
| 36 | while(system_time) |
| 37 | { |
| 38 | system_time--; |
| 39 | ticks++; |
| 40 | update(); |
| 41 | } |
| 42 | |
| 43 | draw_ticks++; |
| 44 | draw(); |
| 45 | |
| 46 | if(iFrameRate) |
| 47 | { |
| 48 | text_mode(-1); |
| 49 | textprintf(screen, font, 0, 0, -1, "Framerate: %dfps", framerate); |
| 50 | } |
| 51 | } |
| 52 | |
| 53 | // code clipped |
| 54 | |
| 55 | } |
iTimer_Speed is set to 60.
Sprinkle your code with printf's and see where the last one executes.
It's executing fine, it just doesn't get to the update function. When running under debug mode, once it freezes, I can throw a break point anywhere in the code that isn't called under the update portion and it will break there. system_time just doesn't increase for some reason.
Are you 100% certain its not memory corruption? I'm out of ideas off the top of my head. If you want to bundle up all the code maybe I can look at it.
Are you 100% certain its not memory corruption?
Like, an out of bounds array or something? Newing without a delete? If that's what you're asking, no, I'm not 100% sure and the program has gotten pretty big, it would take a while to evaluate (although, I'm pretty meticulous with creating the destroy portions once I create the allocation portions).
What version of Allegro are you using? I ask, because I've noticed on Windows and using 4.2 version, I get problems (lockups and such) with start up / shutdown....but is entirely random. I know it's not my code, as it's happened to several different programs made with this version of Allegro. It's really frustrating, and I haven't been able to isolate it. I can't really do anything to get it to do it all the time, so it's hard to report as an error. I think it has something to do with thread synchronization (possibly with the DirectX driver or the timer system?) I don't know about DURING program execution...I can't remember anything off hand. I just started using the 4.3 version of Allegro, so we'll see what happens with that.
I'm using 4.2.
Yeah, it's incredibly frustrating. It shows up rarely and in the middle of running the program. I can't be like, "ok, I'll run the program and play it until it freezes" because it may not even happen that time. 
I suggest trying the 4.3.10 version and see if it does it with it. There are SOME differences, but there is a compatibility layer it seems. For example: there is not a textprintf function, you must use textprintf_ex and such. That, to me, sucks because you don't get the transparent text with the text_mode(-1) option...as it is gone as well.:-/ The good thing is that you can still use these functions under the compatibility layer. I think they removed these because of issues with the true type fonts and such. I noticed issues with add on libs for 4.2 that used true type and those functions. If you don't have or want the 4.3.10 version of Allegro, I could compile it for you and we could both check to see if we could reproduce this "error" again.::)
I switched to using textprintf_ex a while back (can't remember why). You can just use -1 in the function for transparent mode.
I've had problems like these as well, and so did X-G's Cosmic Invaders program. I don't think it is directly caused by the code we're using for our programs. My guess is that the DX drivers on Windows for Allegro 4.2 have some kind of threading issue, but if they do, it's insanely hard to debug because it's so random.
The problems I've had include windows that are running normally (according to Windows), but are not receiving visual updates. If the window title bar is held and the window is dragged around, then the window updates again. This is reproducible fairly consistently for me with several of the example programs - exdbuf, and exflame do it, and probably more as well. Both use GFX_AUTODETECT as the first graphics driver to try, and the screen flashes several times while it's trying to find a driver that doesn't fail. I think the fact that the graphics driver fails to be set several times is the direct cause of why the little 320X200 window they finally open is all borked. That kind of problem is mainly with the example programs though.
The problem I have with my programs once in a while is pretty similar. The window will freeze without Windows detecting the program as non-responsive, but in this case, it can't be forced to visually update by moving the window.