Forum Replies Created
-
Posts
-
Interesting. If it was different before, that was actually unintended behavior prior to this update. After trying a bit I agree that it feels better when the emulated button registers before the trigger click though, no problem technically.
I’ll uploud a new setup later today. I won’t bump up the version number for this change, so no auto update. A manual reinstall will do the trick.
19/07/19
vorpX 19.2.2 has been released.This is a maintenance release, it’s most important change is support for Index and Windows Mixed Reality controllers, including full keyboard/gamepad mapping ingame visualization and (alternatively) animated hands.
- SteamVR input redone. Now uses the (not so) new VRInput() system.
- Valve Index controller support
- Windows Mixed Reality controller support
- Oculus Touch support in SteamVR mode
- Fallout 76 Geometry 3D fixed (was broken with latest game version).
- Correct hand/weapon scale for Skyrim/Skyrim SE
- Positional tracking improvements
- Unity 5 base profile fixed.
- OpenVR (SteamVR) library updated to 1.4.18
- Various minor fixes and improvements.
Depends on which mode you play in and how close/far you set the screen distance in cinema/immersive screen mode. The closer you set the screen distance the more pixels you need for 1:1 pixel mapping to the display, so there is no one-size-fits-all answer to your question.
The only rule you need keep in mind is to set the resolution as high as your PC allows without sacrificing too much performance.
The game always gets rendered at the resolution you set. The resolution vorpX uses for the second step when the final image is sent to the headset is usually larger and never smaller.
If you change the setting while vorpX is running, vorpX will reset it on exit to the state at launch. That is intended (see above) and probably what happend.
The Microsoft Store probably is the curlprit here. Most (if not all) games from the Microsoft Store are protected against any kind of code injection.
I’ll take a look at it. Normally vorpX should read the current state when you start it and then reset it on exit if it changed while vorpX was running. That is done because you can disable mouse acceleration in the vorpX ingame menu which can make sense for better head tracking in older games. The reset to the launch-state on exiting vorpX is a failsafe in case a game that changed the setting crashes.
What is not supposed to happen though is that vorpX changes the state on launch. Can’t really imagine currently how that would be be possible, but I’ll check it to be sure.
There is no single benchmark that you could use to determine how well vorpX works as that depends heavily on individual games. In a nutshell: old games run typically better than the latest, more demanding, ones and both GPU and CPU performance are important. Impossible to say anything more specific due to the vast amount of entirely different situations you may want to use vorpX in.
Just to add another aspect to the discussion I’d like to mention that at least as far as Oculus users are concerned AMD’s market share is below 10%. See the Oculus hardware survey here: https://developer.oculus.com/hardware-report/pc/
This is worth considering when you make a choice because VR devs spend more development time with cards the vast majority of their users have, so those are typically better tested. Shouldn’t be your main reason to decide for or against a GPU vendor, but it’s worth to be factored into your decision making.
Nothing to worry about. The old SteamVR input API only really supported Vive wands, they deprecated it a while ago in favor of their new, more flexible VRInput() system. Hence the part of vorpX that used the old API had to be rewritten to allow full Index controller support.
I did the wrestling with the SteamVR mapping, the only changes you will notice are for the better, i.e. support for more controller types. You can still map the controllers in vorpX like before. Also all existing setups still work and are fully interchangeable between controller types as far as possible.
You can try a new profile from the cloud with yet again changed z-buffer heuristics. Works for me regardless of display mode and with two different save games. This was definitely the last time I touched this game though, sorry. If it doesn’t work for you, there is nothing I can do anymore.
This is one of the games that seemingly randomly switch depth buffer textures. Unfortunately it is not possible to track such changes 100% reliably under all circumstances.
That’s not how I meant it. I think you reported Z3D issues with this game about 3 or 4 times in the past and I spent an highly disproportionate amount of time on it already to somehow get it working reliably. If not even that proves enough to fully stabilize the z-buffer extraction, there is not much of a choice unfortunately. Sorry again and thanks for your understanding.