* changed color overlay to use gain values instead of overlay
* moved SS/Motion smoothing, and filter to video tab
* began refactor of steamVR qml page
* added misc toggles to steamvr tab
* added imu fallback and DND, and some qml formatting
* added Camera Settings to SteamVR page
* changed formatting to minimize height
* added video profiles cleaned up steamvr controller
* delta comparison change
* added profiles for video
* fixed display bug in colorgroupbox and removed frivoulous saves
* removed commented code
* added custom keybind buttons
* removed velocity fade dependent fade.
* changed floating point comparisons
* explicit conversion changes
* removed head speed calculation from overlaycontroller as no longer used
The page was not made with Arch in mind.
The currently required were tested on Manjaro, more packages may be
explicitly required due to the bare-bones nature of Arch.
Adds simple logging calls makes debugging easier.
The initial build script was basically ported over directly from
Windows. It was written because I at the time didn't understand
compiling on Linux, and the existing standards, very well.
Moving as many build components into a program specifically made for
building C++ makes everything much easier.
The old build script is still used on CI where control flow can only be
changed using environment variables.
`bear` and `clang-format` are only used on the CI, there's no reason to
include them here.
This reverts commit e712f4aa1f.
The issue turned out to be isolated to Linux, since it wasn't possible
to reproduce the issue completely on Windows.
An MVP for the bug can be found here
https://github.com/username223/SteamVR-Manjaro-Sync-Crash
The issue is very likely to be on SteamVR's end, since the issue doesn't
appear on the same CPU running Windows.
The fix for the issue in
https://github.com/OpenVR-Advanced-Settings/OpenVR-AdvancedSettings/issues/252
is to by default turn off the offending feature. This doesn't fix
anything, but it will prevent people from having OVRAS kill their
performance just by running the application.
This enables a `sudo make install` that copies the build directory to
the PREFIX directory (/opt/OpenVR-AdvancedSettings/AdvancedSettings by
default).
The entire directory is being copied because Qt is incredibly weird
about how the INSTALLS variable works. From testing it appears that only
files that exist before the build process has started (even the
file_copy process) will be eligible for installation.
If the /OpenVR-AdvancedSettings/ directory is excluded, Qt will attempt
to remove the /opt/ folder on `make uninstall`, this is obviously not
desirable.
As described in issue
https://github.com/OpenVR-Advanced-Settings/OpenVR-AdvancedSettings/issues/266
the gcc-9 libstdc++ version is not included in Ubuntu 18.04 or
derivatives, which leads to a runtime error.
gcc-7 is the oldest version that has c++17 support. If we didn't need
C++17 support then we could use gcc-5, which is included with Ubuntu
14.04.
`qmake` is better suited for finding `windeployqt`, since it's in the same
directory as `qmake` on windows.
`qmake` is also better suited for finding the build target
(release/debug) vs third party scripts.
`windeployqt` is being forced to run in `cmd` because the syntax is
different for running executables in powershell, which means
`windeployqt` won't be executed and runtime or package errors will
occur.
With the removal of the windeployqt call the deploy step is no longer
needed for building on Windows, since all previous deploy tasks are now
handle by Qmake.
The logs are stored in `~/.local/share/AdvancedSettings-Team/OpenVRAdvancedSettings/`, but the config file is stored in `~/.config/AdvancedSettings-Team/`.
Described in commit 97e203fd89e7cb54c7ce96ce779b2e8cb6ac1374
The python functions are no longer needed since the python script
doesn't handle file copy any more.
Described in commit 97e203fd89e7cb54c7ce96ce779b2e8cb6ac1374
The linux directory in package_files is included even on Windows install
for simplicity and because it takes up less than 1KB.
Having the application call Sync() every frame led to slowdowns on some
4 core CPUs and instant crashes on some older CPUs.
This makes the chaperone velocity modifier only update on every 101st
frame. This might not be the ideal framerate, but having it update every
frame makes the app crash on start for some users.
On Manjaro with a i7-6700K (4 cores) this led to instant crashes of
SteamVR+Steam+OVRAS, with a SEGFAULT in SteamVR.
Issue here:
https://github.com/OpenVR-Advanced-Settings/OpenVR-AdvancedSettings/issues/252
Having to wait for OPs to respond with details that should have been in the original issue is getting a little annoying.
This will reduce the amount of freeform writing required by people to produce a usable feature request/bug report.
Kung-vr
ykeara
Vasily
Kung-vr