Forum Replies Created
-
Posts
-
That is definitely not supposed to happen, should return to the prior state normally. If that happens often, disable the virtual monitor in the config app.
Would be great if you could answer the following question so that I have a starting point for replicating the problem: how do you invoke the virtual monitor? By switching your physical monitor off manually or by launching the desktop viewer and then putting on your headset?
If you happen to use any other antivirus than the built in Windows Defender, try to
- Disable it (might be hard for the extra annoying ones)
- Exclude the vorpX program folder (usually C:\Program Files (x86)\Animation Labs\vorpX
- By far the best option: get rid of it. Windows Defender for all intents and purposes is more than good enough since more than a decade and I usually make sure any new release gets whitelisted by Defender if necessary.
Not really, that’s sheer luck with the default hooking mechanism. When using a hook helper or alternative hooking both hooks probably always occur in the same order, but if that’s the wrong one, trying default hooking until it works is your best bet.
Interesting. I’m surprised it hooks at all. May be related to some game overlay and depending on whether vorpX comes first it works or doesn’t (or vice versa). Just a guess though.
If you mean head tracking mouse emulation not working currently in desktop viewer: next update. That’s a bug, not sure yet why it happens. Either next week, or if that doesn’t work out, in a couple of weeks.
I see. Vulkan is not supported. The desktop viewer is the only option in that case.
Your actual monitor should come back after a while when something goes wrong with the virtual monitor. At the worst about 30 seconds after taking off your headset.
You can also disable the virtual monitor in the config app. It’s quite useful though since it comes with many vorpX specific resolutions predefined and runs at the refresh rate of your headset for a uniquely (at least I think so) smooth desktop experience.
Probably related to nVidia drivers 580.88+ causing a black screen in DX12 games with any vorpX version prior to 25.1.0. Fix here: vorpX 25.1.1 Available Now
Disclaimer: I have not tried the profile, and can’t say anything about its quality. Just got curious since profiles disappearing from the cloud might have indicated some server issue.
There is a profile named ‘Final Fantasy VII REMAKE (OLDDONT USE)’. Probably that’s the one bjr84 meant.
The game has a bug where beyond a certain FOV it doesn’t render all world geometry/messes up some LODs, hence vorpX caps the FOV at that bug-threshold. It’s either an FOV sightly below what would be possible on a Q3 or glitchy graphics. Probably not considered a bug by CD Project since the threshold lies well above the max FOV allowed in the game options, so it’s unlikely that they’ll ever change that.
All good, glad you got it sorted. Always a good idea to use a VR headset when checking a VR app, I guess. :)
I have updated the profile with the new HUD shader definitions. Should work again with a scaled HUD now, at least until some TESO update breaks it again.
An updated profile database should download automatically when you launch vorpX next time. If not you can grab the profile on the cloud profiles page of the config app, it’s named ‘The Elder Scrolls Online [vorpX]’, the [vorpX] indicates that this is the official profile you want for updating the shaders.
I see. I settle this issue then. Please try some other games. Preferably some with official profiles.
“while with Vorpx it’s limited to client area”
That is to be expected and on purpose. It’s meant to keep the mouse inside the game window when run windowed. Some, especially older, games don’t handle that correctly by themselves and don’t work right without catching the mouse. I’ll put SpaceEngine on my nice-to-have official profiles list, looks interesting enough. There I would be able to override this behavior.
Can’t say anything more to your input issue before running some Windows 10 tests myself. So far no other reports like this several days after release though, which hints more towards an individial config issue than something general.
I somehow doubt logs will contain anything really useful in this case, but please create a trouble shoot data archive in the config app and send it to support at vorpx com. With some luck I can spot something.
Interesting, never heard of that. vorpX does use GetAsyncKeyState(), but not in the hooked game. It updates the keyboard state in the vorpControl app and then relays that to the game via interprocess communication. It does hook the function though inside the game for various reasons. I’ll check TR3 in Windows 10. If I find something unusual, I’ll let you know.
BTW: vorpX quite heavily relies on interprocess communication like the one described above between all its parts, which makes mixing components from different versions dangerous and likely to cause havoc. Don’t do that.
Just in case you may also try a uninstall/reboot/reinstall like I suggested to Dellrifter above. Just to be 100% sure everything is really at 25.1.1.
Yes, it’s supposed to resume after exiting a game. Also the auto recentering every 5 seconds is not supposed to happen, only once when the desktop viewer switches to the virtual monitor. For the lack of a better suggestion, try a uninstall/reboot/reinstall. Maybe the background service didn’t update correctly for some reason. Both the not-resuming part and the recenter issue point at something being wrong service wise.