Forum Replies Created
-
Posts
-
Please check whether you have some other DirectX injector/mod installed in the game folder. Or maybe some game recording app running. Remove anything that potentially may also hook into DirectX and by doing so may cause double injections and other weird issues. This does not happen with vorpX alone.
25/09/12 | vorpX 25.1.2 has been released
Another maintenance update with about a dozen noteworthy changes and fixes.
- Head tracking mouse emulation did not work anymore in desktop viewer.
- Messages shown in some games on start could become unresponsive.
- Mod component install with the virtual display failed due to an unclickable prompt.
- Some games did not exit cleanly since vorpX 25.1.0.
- Workaround for 32-bit games that use too much RAM on CPUs with many cores.
- Potential workaround for old games that assign small stack sizes (untested).
- In games with .ini and mem-scan FOV, ini-controls weren’t shown before scanning.
- Avoid more annoying virtual monitor related Quest Link self-restarts.
- Communication between the service and 32-bit vorpControl was broken.
- The service could use an entire CPU core after lock/unlock, standby/resume etc.
- Custom sync selection in the vorpX menu selected different options than shown.
- Trouble shoot data now includes all relevant log files.
- Better service handling in the installer.
- Elder Scrolls Online: HUD shaders updated (again).
- Cyberpunk 2077: mod components updated for CP2077 2.31
- As always numerous smaller fixes and optimizations.
2025/09/12
A new update is available that adds support for Cyberpunk 2077 2.31 and updates the core components to match the latest vorpX version.
Download link as always in the first post of this thread.
The whole point of the virtual monitor is less fiddling with custom resolutions. The current way to add your own via the – fairly slick if I may say so – dialog is as far as customization will go. Sorry. It’s actually already the result of listening to user wishes about more customization, although that rarely should be necessary at all.
Aspect ratios below 1:1 practically never makes sense since in FullVR you’d always want a few pixels left and right as a buffer for extra frames vorpX can generate. In games that aren’t too demanding actually even 4:3 is the best FullVR choice, as that will provide enough buffer for fast head rotation without black sliding in from the sides. And in terms of wider resolutions everything is there that makes sense for immersive screen/cinema.
If what you have in mind is adding precisely the display resolution of your headset, that’s not how things work in VR. There can’t be precise pixel mapping due to the reverse lens distortion applied to the image on screen anyway.
I can’t really think of much else than the bug I described above, 90% sound particularly weird as that would mean the service used almost all your cores, which it never does. At worst it should occupy one core when said bug occurs. Let’s see how things turn out after the next update. Keep me posted once the next version is out.
Resolution:
Disable foveated rendering in the Pimax app. Can’t test since I only have an older Pimax lying around here, but others reported that’s the source of the problem. Foveated rendering is not of much use with vorpX anyway since when hooked into a game most of the GPU heavy lifting is done by the game, not in vorpX’s own rendering thread where the foveated rendering gets applied.
Desktop viewer/virtual display:
Sounds suspiciously as if the vorpX service can’t perform its desktop viewer related tasks like it is supposed to on your system, which would prevent both the virtual display from kicking in and the desktop viewer from launching when trying that from the tray menu.
That may occasionally happen due to bug that can send the service into an infinite loop currently. Will be fixed in the next update. As a workaround restarting the service (or your PC) would help until then.
It can also happen if you are running your PC with dedicated admin/day-to-day user accounts, where the logged in day-to-day user user is never allowed to have admin rights. To use the virtual display as intended you’d have to change your Windows setup to default (i.e. the logged in user can obtain admin rights via Windows’ user account control if needed). If you don’t want to change that, you can still use the desktop viewer with your actual monitor like you currently do, of course.
If none of the above is your issue, try to reinstall vorpX if you haven’t tried that already. Just in case.
Under normal circumstances the service should not consume any noteworthy CPU time.
However, there currently is a fairly stupid bug that can occasionally cause this after lock/unlock, waking up from standby or similar events. Unless your issue is caused by something else, it should be fixed in the next update.
If you still experience this issue in vorpX 25.1.2, which will be out shortly, let me know.
The profile currently has no gesture predefined. You can add some yourself though. Check the video in the release post for a short introduction.
Can’t replicate. Checked with Odyssey under various conditions. Neither in generic 3d, nor with a headset, with and without virtual monitor. One time I had to ALT+TAB after opening the game’s key rebind options for some reason though. Might have lost input focus.
That aside I could rebind the C key to everything I tried. vorpX wise everything at default.
The C key is used in the ALT+C hotkey for toggling cursor visibility if neccessary per default. Nothing has changed in that respect for ages though.
Would be great if you could check whether the same happens with a different key you assign in the config app for cursor visibility toggling or whether it’s still the C key that causes issues afterwards. Both would be equally weird, but at least I’d have some halfway useful information that way.
You should be able to automate large parts with a batch file and some command line tool that can change the resolution. An alternative would be AutoHotkey, which can change display resolution itself, I think. Never used it, but many consider it quite useful for Windows automation tasks.
I’ll add a selection for a preferred virtual display res in one of the next updates. Probably not directly the next, but that sounds like a useful idea.
Nothing has changed in respect to immersive screen controls. The profile now comes with a dedicated mod-portion though. You may have to disable that on the DirectVR page of the menu, switch to Z3D, immersive screen mode on the main page and restart the game to make everything behave like before.
Builds prior to 25.1.0 don’t work anymore with Cyberpunk at all since nVidia decided to break vorpX’s old DX12 renderpath in drivers 580.88+.
As said above already, there might be nothing to fix on my end. Meta, WMR, even Valve within the boundaries of its flaws work. So to me it looks quite a bit more likely that the Pimax OpenXR runtime does something weird. I’ll still check, of course.
I see. I’ll check whether my old Pimax uses that. OpenXR should be universal though, taht’s the point of it. So without having tested anything, I would carefully tend to blame the Pimax OpenXR runtime for your issue. I’ll check anyway.
Do they have their own OpenXR driver independent from SteamVR or do they use Valve’s god awful (no 32-bit support, broken multithreaded syncing) OpenXR runtime?
In the latter case using SetamVR directly is better anyway. The latest vorpX should actually do that automatically if it detects that Valve’s OpenXR is set as the active OpenXR runtime.