Due to the SettingsController being a static object it will be
initialized before the main method has been run. This will cause
easylogging to log using the default logging style instead of the
defined application style. Because of this the settings are propogated
up through a function into the main method.
The `customTickRateMs()` function is being called every millisecond,
adding the verification to every call leads to unnecessary overhead.
The tick rate is verified when loading and when saving.
After looking at the assembly output it became apparent that the Windows
compiler did not compile out the `getSettingsController()` function
call.
This led to an unnecessary function call in order to get the
SettingsController. Turning it into a static object in the compilation
unit scope removes this function call and turns getSettings call into a
single instruction (not counting zeroing the register for comparison and
the jump instruction afterwards).
----
Adding the following code to the `main` function:
```cpp
f ( settings::getSetting( settings::BoolSetting::UTILITY_vrcDebug ) )
{
LOG( INFO ) << "Enabled";
}
else
{
LOG( INFO ) << "Disabled";
}
```
Leads to this with the `getSettingsController` function:
```assembly
[...]
47 if ( settings::getSetting( settings::BoolSetting::UTILITY_vrcDebug ) )
0x7ff6c96819a0 <+ 1024> call AdvancedSettings!settings::getSettingsController (00007ff6`c96cd280)
0x7ff6c96819a5 <+ 1029> xorps xmm0,xmm0
0x7ff6c96819a8 <+ 1032> cmp byte ptr [rax+5FCh],0
0x7ff6c96819af <+ 1039> je AdvancedSettings!main+0x4fd (00007ff6`c9681a9d)
49 LOG( INFO ) << "Enabled";
0x7ff6c96819b5 <+ 1045> mov qword ptr
[rsp+288h],r15
0x7ff6c96819bd <+ 1053> mov qword ptr
[rsp+290h],rsi
[...]
```
And this without the function:
```assembly
[...]
47 if ( settings::getSetting( settings::BoolSetting::UTILITY_vrcDebug ) )
0x7ff7d97a19bb <+ 1019> xorps xmm0,xmm0
0x7ff7d97a19be <+ 1022> cmp byte ptr [AdvancedSettings!settings::settingController+0x5fc (00007ff7`d9854d4c)],0
0x7ff7d97a19c5 <+ 1029> je AdvancedSettings!main+0x4f3 (00007ff7`d97a1ab3)
49 LOG( INFO ) << "Enabled";
0x7ff7d97a19cb <+ 1035> mov qword ptr
[rsp+288h],r15
0x7ff7d97a19d3 <+ 1043> mov qword ptr
[rsp+290h],rsi
[...]
```
Notice the missing `call AdvancedSettings![...]` without the function
and that the settings call literally cannot be made any faster.
The color*New settings were a hotfix for 4.0.1 where wrong settings were
applied to the colors leading to a black headset screen.
The New postfix is to manually prevent the settings file from reading
the old values.
Only the existing changes were moved.
The remaining were not initially added because they didn't show up in
the .ini files I based my initial prototypes on.
The details of the API are in the `/docs/specsSettings-API.md` file.
The enums do not list all available settings, more are to be added as
the settings API replaces inline QSettings calls.
The current interface is almost exclusively in written English.
This makes usage of the program more difficult for people who can't
distinguish English words, or remember specific VR/English technical
terminology.
Adding small icons to main menu items will make it easier for the
aforementioned groups to use the application.
This also adds the ability for buttons in general to have a custom icon,
if necessary.
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.
Vasily