internal/graphicsdriver/directx: Directx driver causes go program exit when screen blanks or user locks #2179
Comments
|
Can confirm opengl works as my naive expectations, it just keeps working in the background. Workaround for others that see this, place this before your main game loop: |
|
Thanks, I'll take a look! |
|
Confirmed. |
When a screen is locked, an Ebitengine application crashed as the swap chain's Present returned DXGI_STATUS_OCCLUDED. Let's ignore the error and continue to run the applications. In the ideal world, an application should stop running during the screen lock, so let's revisit this later. This fix also fixes the issue that a Win32API GetCursorPos returned an error ERROR_ACCESS_DENIED when the screen was locked. Closes #2179
|
OK I've fixed the issue. Could you try Thanks! |
Ideally this seems the way to go. The current implementation is just to ignore the error. I'll consider a more sophisticated way at #2181.
I see. I'll let applications work behind the lock screen. You can control the behavior when unfocused with
IIUC testing presenting with |
Confirmed that game doesn't error out when I lock the screen with directx and this change any longer, I'll resume using directx to help find any other issues with it as soon as it makes it to v2 officially. |
|
Thank you very much! |
hajimehoshi
changed the title
Hi! I'm using v2.3.5 (newest v2 release as of right now) on Windows 10 with the directx driver in use. If you are running an ebiten executable and lock the screen or the monitor suspends due to windows settings the program
ebiten.RunGamereturns with an error. You can see this behavior with the examples.Here's the error:
It is really easy to reproduce, just run a program and hit the keys
winkey-l(that's a L) to lock the screen. Unlock the screen and you'll see the error.Is there a way to just re-invoke the Run call and it will leave off where it started as a workaround?
A naive expected behavior would be that ebiten wouldn't care about this error and continue with update calls and ignoring the presentation error, perhaps pause draw calls until the machine is back in a state where present wouldn't cause an error?
This is how most games on windows work, when my monitor suspends I usually can hear the sounds and the game events keep going in the background. Think idle games where this behavior is important. My current project is a long running simulation which is important to have this ability too.
Another option is a pause of the engine until directx will process the Present? However, if that is an option I'd like it a configurable behavior.
One way to tackle this (and maybe it does?) is to register a callback on these kinds of errors/events that cause them and the game logic can return in the callback if it should suspend processing or continue updates without display in the meantime? Maybe return timeout where the game engine will check again and call the callback again if it still can't Present?
The text was updated successfully, but these errors were encountered: