I'm assuming this is related to the information provided in the description of ALLEGRO_EVENT_DISPLAY_LOST. I'm using Direct3D on Windows 8.1, with Allegro 5.2.2.

After locking the computer or having the screensaver appear, sometimes bitmaps are replaced by black boxes. Sometimes they aren't. I assume they're getting lost and Allegro is unable to restore them. However, sometimes they'll reappear on their own after locking and unlocking the computer a number of times, or by having the screensaver appear/disappear again. Toggling fullscreen with al_toggle_display_flag almost always seems to restore them as well.

Why is this? Why does it have trouble restoring them sometimes, only to successfully restore them later? If toggling fullscreen somehow restores them, is there something I can do to make it so however it's restoring always occurs?

If this inconsistency is normal, what's the best approach here? The bitmaps are loaded from the file system with default flags. Do I need to free them, then load them from the file system again? If they still exist in memory somewhere (since they're restored sometimes, they must be), this seems like an inefficient approach.

The intention for it is to be consistent, but it appears that there might be some issue. It will be helpful if you turn on logging and see if the logs differ between when the bitmaps succeed in being restored, and when they fail. You can turn on logging by adding this line before al_init():

al_set_config_value(al_get_system_config(), "trace", "level", "debug");

That will produce an allegro.log file in the working directory of your program.

In terms of workarounds, we have this function al_set_d3d_device_restore_callback in which you can in principle reload all your bitmaps. It might be useful to pass it a callback and see if it's called reliably as well.

Lastly... while we have all sorts of checks against it, try ceasing your drawing code when you receive the ALLEGRO_EVENT_DISPLAY_LOST event (and resume drawing when you get the ALLEGRO_EVENT_DISPLAY_FOUND event) and see if that helps.

Thanks a lot for the reply! Here's what I've discovered:

After enabling logging, I generated two logs. For each log, I locked the computer once, then unlocked it. I've included what I believe to be the important portion of each one.

Here's what happens when it successfully restores the bitmap:

Here's what happens when it doesn't:

It seems the device is lost, and then... Nothing.

Here's one more log where it failed to restore the bitmap after the first lock/unlock, but successfully restored it after the third lock/unlock:

I added the callback as you suggested, and when the bitmap is restored successfully, it gets called twice. When it is not restored, it only gets called once.

Finally, I tried suspending the drawing until the display is found as you suggested (by setting a flag to false when ALLEGRO_EVENT_DISPLAY_LOST shows up, and to true when ALLEGRO_EVENT_DISPLAY_FOUND, and only drawing when it's true). The same issue came up.

If you want to see the code, let me know and I'll post it. In case it's relevant, I'm using Visual Studio 2015 with the Allegro nuget package.

That's very interesting, thanks. I'll take a look at this soon as I've been looking into this system recently.

EDIT: Still working on it, no luck so far.

Were you able to reproduce it, at least? If there's any other useful information I can provide, please let me know.

I may need to get your source after all. I fixed one device loss issue, but it doesn't look like yours. In particular, I'm trying to get these lines to happen for me:

d3d D d3d_bmp.cpp:539 _al_d3d_sync_bitmap [ 0.10467] _al_d3d_sync_bitmap (system) ref count == 1

. I saw those before, but I can't seem to get them again.

Sorry for delayed response! Here's the code:

And some extra information, in case it might be helpful:

- I'm using C++ (obviously) rather than plain C, if that makes a difference.
- Compiled for x86 in Debug mode with Visual Studio 2015 on Windows 8.1 64-bit.
- I tested it out on another computer to see if the logs differed; they were the same.

"allegro_logo.png" is this image.

I tried your code, but I just can't get it to reproduce your issue. I think the best I can do at this point is describe how I'd approach fixing this if I could:

1. First, I'd turn on the debug runtime for DirectX using the DirectX Control Panel (not sure where I got it), it'll look like this:

{"name":"610974","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f8ac8a265d1f9dedd969b80211cc8e5f.png","w":401,"h":531,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f8ac8a265d1f9dedd969b80211cc8e5f"}

2. Running your program in the debugger in MSVC will now print various logs, that may be useful.

3. Stepping through Allegro's code is essential. The Nuget package comes with debug symbols, you're just going to need to download Allegro's source and point the debugger to it (see https://msdn.microsoft.com/en-us/library/ms241613.aspx). What to look at here will depend on what errors #1 returns.

I opened up the DirectX Control Panel, and all of the debugging options are greyed-out. After doing some research, I found that apparently the debug version isn't available in Windows 8.1 (or Windows 7 post-KB2370838). Support for old versions of DirectX was dropped. It seems like it's possible to get around this by modifying a registry key in Windows 7, but I'm out of luck on 8.1.

I'll probably set up a VM to do this, but I'm definitely not looking forward to installing everything...

Maybe I can try doing this with Win10 in a VM as well (I have Win7 as my real Windows).

All right, I got everything set up. The following is shown in the debug output log when it fails to restore the bitmap after a lock/unlock:

Direct3D9: (ERROR) :Lost due to display uniqueness change
Direct3D9: :DoneExclusiveMode
Direct3D9: (INFO) :Using FF to VS converter

Direct3D9: (INFO) :Using FF to PS converter

Before (and after that), it's continuously spamming Ignoring redundant SetSamplerState, but I doubt that that's important.

I wanted to see if it wrote anything different when it managed to restore the bitmap successfully, but I can't get it to do so in the VM. It never restores the bitmap, and presents the same output with each lock/unlock.

I'm sorry to say I wasn't able to figure out how to get step 3 working. The page you linked said I can specify the source files under "Common Properties / Debug Source Files", but "Common Properties" doesn't exist in VS2015 Found it, I'm an idiot. I just need to specify the source directory, right ("allegro5-master\src")? I did that, but it's not letting me "Step Into" Allegro functions...

Do I need to worry about specifying .pdb files? When it asks for "allegro.pdb" I tried selecting "packages\Allegro.5.2.2.1\build\native\v141\win32\lib\allegro-debug.pdb", but that's not what it's looking for.

Pardon my ignorance-- I want to help, but this is not a familiar process.

You want to link to Allegro's debug versions, which will automatically pick-up the pdb files.

EDIT: Actually, it's pretty great that you got it failing on a different Windows version. I've been trying this on my virtual Windows 10 to no avail.

Yes, that redundant sampler state thing is harmless... but is that really all the errors it shows? What does the log look like when it succeeds to restore things?