It looks like you're new here. If you want to get involved, click one of these buttons!
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?
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:
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:
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.
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.
My pleasure. It's not optimal but it's better than nothing!