Ok so to make a long story short I narrowed down the problem I've been having with the lost and found event to something that's easily built and executed by anybody.
To test it:
Tab-out and back repeatedly until it fails to re-enter correctly. On my computer, it eventually (and simply) does not re-enter after tabbing out. To kill the application I press escape.
You may have to tab out and in a couple dozen times. Or not. It's random.
Now I did figure out which line is causing the trouble. It appears to be:
So it seems if I target the pbitmap in the render function the reset fails sometimes.
Try it yourself. This is just what happens on my system.
Again, the problem is the reset fails.
I'm using Allegro 5.1.4 on Windows Xp Sp3.
Here's the code:
Try this:
Well when I tried your code as-is it didn't get rid of the problem.
However, enabling NO_PRESERVE and just destroying and recreating did.
Now...
In my main application I have made some progress.
I found out that the problem is occurring in the destroying process that happens immediately after the lost event. Somehow an al_destroy_bitmap() call is failing. This is of course later causing reset to fail.
Right now, I'm using ::al_is_d3d_device_lost() to test if the device is lost in different places. I've figured out that those cases where the device is unable to reset correctly happen when the device is lost INSIDE the display routine (bundles all of the rendering for the application). So even if I skip the display routine if the device is lost (which I am currently doing), it can still happen inside. And somehow that's causing this problem.
Basically, it looks like even if I use the code that you supplied - that uses callback routines - I'll still have this problem. I have to dig deeper to find out exactly where it's happening and if I can do a test when I'm destroying.
I may have said something wrong, but this is the gist of it. The display is lost inside where I use allegro display routines and somehow it's choking something that prevents me from destroying a bitmap.
I've said it about 8 times now and this is the last. You can't do anything with d3d after returning from the release callback until returning from the restore callback. NOTHING. al_is_d3d_device_lost takes a snapshot of the flag at a given point but it can change in the middle of your function. The ONLY way to do it right is as I said above, and on top of that set a flag that says DON'T TOUCH D3D in the callback. This assumes your program is single threaded, in a multi threaded program it's slightly more complicated.
Trent I haven't used the callbacks yet in the main app. I did test them in the skeleton app briefly.
But I will put them in the main app now.
Sorry bro if I touched feathers. Look, I've had a lot of troubles with this code and this has been a rough ride. I've not enjoyed myself. Please don't get too mad.
I love the help. I know I might be a tough student, but I'm trying.
Ok ok, I got a little impatient. No worries.
I'm using the callbacks now in the same way as your sample code.
But here's the problem... hail_main_thread is only true when I re-enter the application. Am I doing something wrong? What's happening is the device is getting lost before I get the lost event. And halt_main_thread is not true so the release_callback() isn't being called yet. So how am I supposed to prevent allegro functions from being used when the device is lost before it reaches the allegro message pump?
Well I'm just at a loss. Don't understand.
I'm trying to use al_is_d3d_device_lost() but it's not preventing it. I do use it to skip the main routine for the display, but somehow after that it fubbers. When I put it inside it oddly is somehow not recognized until the display flips.
As in:
Can lock this thread. If I need anymore help and Trend has ignored me or something then I'll ask him. I've made too many threads already. This is going on and on and on. I'll shutup. Thanks.
Just.... this has been one of the worst time I've had programming. I've been programming for a long time. I'm 35 and so it has been more than 15 years off and on. And I'm just baffled at this. Maybe I need to learn more about direct 3d. But I'm already hating direct3d. Anyway, whatever. Don't like hitting my head against the wall.
I'm having a bit of a hard time understanding the problem. You're talking about al_d3d_device_is_lost and message pumps and events, and I swear I've said more than once that those are useless for what you're trying to do.
I'm here to help, I'm not going anywhere. Maybe an explanation of what is happening behind the scenes will help (you can look at the code yourself in src/win/d3d_disp.cpp):
1) Allegro receives device lost from d3d. It sends the LOST event which is mostly useless.
2) It waits for d3d to tell it to reset the device
3) It calls your release callback if you've set one
4) It releases all bitmaps including ones with NO_PRESERVE (I may have told you different before)
5) It then resets the device
6) It recreates ALL textures but only restores the content of ones without NO_PRESERVE
7) It emits the FOUND event
8) it then calls your restore callback if you've set one
So with that said, do you have an example that doesn't work that I can test? The one you posted here worked at least enough that I couldn't get it to fail, so something that's more reproducible would be good but if that's all you've got...
And I apologize if I gave you any wrong information before... I want to fix this though so stick with it .
Well first off the sample I posted in the OP fails on my machine about once every ~10 times. When I press alt-tab to re-enter it fails. I can still see the console window except it doesn't have focus. I press escape to exit.
As I said, the line that causes it to fail is the line that targets pbitmap. That's the line that will get executed first after the display is found and the timer sets b_redraw to true. If I remove that line, I get no failures.
The sample you posted in your first reply didn't get rid of it. The only change your sample adds is that when it fails to re-enter it goes into a hard loop and won't respond to me pressing ESC.
I'm using WinXP Sp3 with Direct 9.0c and the Allegro 5.1.4 binaries here:
https://www.allegro.cc/forums/thread/611248/969351#target
I'm using Microsoft Visual C++ 2010 Express to build the project. And no I'm not running any other code alongside the sample I gave in the OP. I just use a #ifdef...#endif in main.cpp to run the sample exclusively.
Again, I fixed a number of issues with d3d lost devices in 5.1.5. Please test using that version or git.
edit: I tested your program with the current git version of Allegro (should be the same as 5.1.5 in this respect). No problems alt-tabbing in and out about 30 times or so.
Peter, have you tested on older versions? I'm just wondering if this is an allegro ~5.1.4 problem or it's a problem on my system (hardware/software). Right now I am in a fog and just don't know.
Where can I get 5.1.5? Rather, how long will it be before a binary is released? I tried building sources a month ago but was only partially successful. Right now, I just wait until the binaries are availabe and use those. I do have the allegro source to look at, though.
I didn't test 5.1.4 because I'd just be hitting the same bugs that I fixed in 5.1.5. I'm attaching the executed I tested with yesterday if you want to see if its fixed for you.
Milan might pop up with 5.1.5 binaries some time, or not. The only hard part about building Allegro is getting the dependencies, and Milan provided them here.