debugging fullscreen in visual studio

I don't think this one is specific to orx, but hoping maybe someone has insight. I'm using Visual Studio 2017. I've found that if my orx game is set to fullscreen and I set a debug break point, bad things happen when the breakpoint is hit. Specifically it becomes impossible to alt-tab to the desktop to see what is going on, or even cntrl-alt-del to pull up a task manager to kill the process. Cntrl-Alt-Del works enough to choose Task Manager, but then nothing happens. The only remedy is to Cntrl-Alt-Del and choose Sign Out. Kind of not helpful while debugging!

Same thing happens if I cause an exception to happen and visual studio tries to come to the top to show me.

Regular windowed mode (fullscreen = false) doesn't have a problem allowing VS to get control.

Is there any way around this? I know I can just debug in windowed mode, which is what I do, but would be nice to be able to in fullscreen. I came across this link that seems to indicate it has to do with the window position flag being set. Is this relevant?

https://developercommunity.visualstudio.com/content/problem/44507/setting-a-breakpoint-in-a-fullscreen-app-project-c.html

thanks

Comments

  • edited November 14

    This issue has been plaguing game development on windows since the dawn of time (or close enough!).
    I've been struggling with it for over 20 years and here's what I can say about it:

    • the main workaround that has been used by game companies for almost 20 years now is simply to have 2 separate monitors: one where the game runs, one for Visual Studio and your issue is gone!
    • when you hit a breakpoint, you can still save yourself the trouble from logging out/rebooting, but you won't be able to debug anyway. Fullscreen, or exclusive mode, means the desktop compositor won't be able to render on that monitor until it can reacquire access to it. And that requires your game to not be "frozen" by, say, a debugger so as to give access back. So when you hit a breakpoint, you should be able to alt-tab (but you'll need to keep track in your head if you don't have any visual cues), and when VS has the focus, you can use F5 to continue or, if your breakpoint is hit every single frame, first deactivate the breakpoint with ctrl+F9, then hit F5 to continue. You should be able to switch back to your desktop once your game has been released by the debugger. Same advice if you kill the game, you'll still have to come back to visual studio and press F5 before the process can actually be killed.

    Now, another work around is to go into "fake" fullscreen mode, aka borderless fullscreen. This is achieved by using a windowed mode of the same dimension than your desktop resolution and without any decorations.
    In order to achieve this in orx, simply omit the ScreenWidth/ScreenHeight properties in Display, and set Decoration to false:

    [Display]
    Decoration = false
    

    You'll then be able to break and switch back to visual studio at will. Unfortunately that won't help you debug a real fullscreen-only bug. In which case you'll need either to have a second monitor or go back to good ol' printf debugging. Been there, done that (I have a single monitor at home). ;)

    In any case, good luck! :)

  • Mmmh, it looks like even borderless fullscreen is dependent on your version of windows and GPU vendor/driver.
    On one machine I tested, I had to first go to the ctrl+alt+del screen, then leave it with escape, before I was able to alt-tab correctly back to VS (ie. being able to see VS, otherwise it wouldn't be displayed).

    By the way, the topmost flag shouldn't be set by GLFW in borderless fullscreen mode, but I have not traced the code to actually verify it.

  • Thanks for all the information....very useful to know. I'll try the "fake" fullscreen technique and see how it behaves on my laptop. I too am fairly accustomed to having to use print statements to find out what is going on when debugging won't work correctly. :smile:
    thanks!

  • Fake fullscreen does work ok on my laptop. When a breakpoint is hit I have to use ctrl-alt-del (alt-tab doesn't work), click task manager, then can click on VS and step through the code.
    Thanks

  • My pleasure. It's not optimal but it's better than nothing!

Sign In or Register to comment.