elvissteinjr
elvissteinjr
The application is open source so there's nothing stopping you from porting it to OpenXR. OpenXR is certainly the future, but Desktop+ heavily relies on SteamVR's overlay system so 1:1...
> I wonder if you learned things along the way that's not in those documents. Hm... hard to say. I've mostly relied on the sample code and went from there...
I had to go and check to be really sure, but yes, Graphics Capture needs a connected desktop even for window captures to output anything. Headless dongles are a low...
I took a look at it seems to behave correctly on my end. It's not supposed to move when pinned to the play-space and re-positions if it's not and dashboard...
Yeah, since the keyboard is pinned in the video it's "working as intended" (has to be pinned, so that happens automatically). The video shows well how wrong these intentions were...
The out-of-dashboard-tab keyboard size is separate from the in-dashboard-tab one. The settings window displays the currently active one, meaning the settings window needs to be pinned and displayed outside of...
Not sure if Overlay Properties is a good fit as the state is still global, but split into the two states, not specific to the overlay the properties window is...
Desktop+'s logging is still very barebones and only logs on a few critical errors, though OpenVR init errors should be reported if they come up. Init errors will display a...
Hm, everything looks about normal. considering the current situation. No Desktop+ overlays in there. UI doesn't load OpenVR if Desktop+ isn't running. It checks for that by looking for the...
That narrows it down at least, so that's something. Another good way to narrow it down further would be to check out the [Win32CaptureSample](https://github.com/robmikh/Win32CaptureSample). Desktop+'s Graphics Capture code is based...