Jump to content
  • Advertisement
Sign in to follow this  
captain_crunch

Fullscreen sometimes throws DXGI_ERROR_NOT_CURRENTLY_AVAILABLE

This topic is 797 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Some users get DXGI_ERROR_NOT_CURRENTLY_AVAILABLE when starting in fullscreen mode.

 

This is the code that throws:


_swapChain.SetFullscreenState(PresentationParameters.IsFullScreen, null); 

The docs say:
 

There are many reasons why a windowed-mode swap chain cannot switch to full-screen mode. For instance:

  • The application is running over Terminal Server.
  • The output window is occluded.
  • The output window does not have keyboard focus.
  • Another application is already in full-screen mode.

When this error is returned, an application can continue to run in windowed mode and try to switch to full-screen mode later.       

 

 

I'm using MonoGame so I can make fixes to the source if I want to. But I have tried to handle the exception at the game level instead, by re-calling ApplyChanges() a few times when this error appears. That's what the docs suggested. 

ApplyChanges() does a lot of other setup too.
 
But, according to the user, he still gets the error. To add to that, I can't reproduce the error myself.
 
Does anyone have an idea to what might help? Should I try to force the window to have focus?
Edited by captain_crunch

Share this post


Link to post
Share on other sites
Advertisement

I would probably even try send him an exe with extra logging around it also, if you are talking directly to the user.   Also, maybe even testing DXGI_STATUS_MODE_CHANGE_IN_PROGRESS maybe?  The whole remote debugging thing isn't fun.  But maybe if the user is co-operative, he can help with the debugging.

 

If the screen doesn't have focus, maybe test for this prior?  

 

I had a look at the directx docs and nothing jumps out, apart from what you have already highlighted.

Share this post


Link to post
Share on other sites

Ask your users whether they have hybrid GPUs (e.g. NVIDIA Optimus or AMD Switchable Graphics).

Also ask them if they have more than 1 monitor plugged.

Also ask them if they've got 1 monitor plugged to the NVIDIA/AMD card while the other card plugged to Intel's integrated one.

Share this post


Link to post
Share on other sites

I will do that.

 

I also added code that tries to force the game window to the front, and take focus, before attempting to go fullscreen again. And I am logging the the different focus properties in a text file. Not sure if it will have any effect.

 

To prevent the crash, I also decided to let the game revert to non-mode switch fullscreen if it does not work.

Share this post


Link to post
Share on other sites

Matias is probably on to something here. If the game is launching on a monitor connected to GPU A, but the game is rendering on GPU B, you won't be able to go fullscreen, because it'll try to use the monitor where the window is.

Share this post


Link to post
Share on other sites

It's the OS that chooses a GPU for the program to run on. The user can also select it in the file properties.

 

I am not sure how the monitor gets picked. For an extended desktop setup, it should be the monitor where the program icon is located.

 

I have a laptop with a monitor attached in an extended desktop setup. The laptop has both an integrated GPU and an nVidia GPU. I don't know how to tell which monitor is running on which GPU.

Edited by captain_crunch

Share this post


Link to post
Share on other sites
Can you even connect a monitor to the NVIDIA card in an Optimus setup? I thought the outputs were always connected to the IGP and the NVIDIA card works by writing into the IGP framebuffer.

Share this post


Link to post
Share on other sites

The OS chooses a default adapter, but the application always has the final choice. D3D11CreateDevice takes an adapter as the first parameter. I see you're using C#, and I'm not sure how the wrappers expose that, but it should still be there. The default render adapter selection is (typically) based on which monitor is marked as the primary monitor (where the system tray is located).

 

The monitor is an optional parameter to SetFullscreenState, if you enumerate it yourself. If you don't, we go for the monitor where the window is currently located. If that's not attached to the GPU that you're using for rendering, you can't go fullscreen**. The monitor where the window launches is kind of random.

 

It depends on the laptop, whether the external outputs are connected to the integrated or discrete GPU. Both scenarios are fully supported.

 

** The one exception is in the Optimus/PowerXPress case, where we enable fullscreen with discrete GPU rendering and an integrated output.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!