Fix FOV Slider + Viewmodel

[jvnpr]

Description

This PR fixes the FOV slider to use the pre-existing FOV option as intended instead of hooking into gameRenderer. It also fixes some other minor issues with the existing FOV system and increases the range of FOV to 30-110.

Changes

Previous Behavior

The FOV slider was inaccurate because it modified a value gameRenderer expected to be hardcoded.

Additional Issues:

• FOV slider is not 1:1 with FOV values
• Hand viewmodel is affected by FOV changes

Root Cause

The FOV slider implemented by 4J in the debug menu (which was used as a reference for the slider in settings) modified the m_fov value in gameRenderer instead of modifying the existing option.

The FOV slider was also implemented as a 0-100 slider and the value was used to calculate an FOV, meaning that multiple stops of the slider corresponded with a single FOV value

The hand renderering code calls for the target FOV, meaning it is affected by FOV scaling.

New Behavior

The FOV slider now modifies the intended option value that gameRenderer expects it to. The FOV slider also now goes from 30-110 instead of 70-110.

The FOV slider is now 1:1, with each tick / stop corresponding to one discrete FOV value.

The hand viewmodel no longer scales with screen FOV.

Fix Implementation

Instead of using gameRenderer->SetFovVal();, the slider now modifies options->fov. This change is used in UIScene_SettingsGraphicsMenu.cpp, UIScene_DebugOverlay.cpp, and Consoles_App.cpp.

Changed how m_sliderFOV was implemented, making it 0-80 to match the range of 30-110

Added a hardcoded value into gluPerspective(); in GameRenderer::renderItemInHand();

AI Use Disclosure

No AI was used to modify the code or author this pull request.

Related Issues

• Fixes [Bug] Hand FOV changes when the FOV is changed in graphics settings #655 [Suggestion] Save user-defined FOV value #666 [Bug] FOV slider is not clamped to Java Edition values #771 [Bug] FOV 110 causes everything to FLIP when sprinting? #838
• Related to [Bug] FOV and Render Distance #802

[codeHusky]

Tests fine, but resets FOV to 30 if you have existing settings prior to this change. Pls fix and then should be good to merge

[jvnpr]

gotta fix some default setting after the merge resolution

[loinmin]

oh cool :0

[codeHusky]

I'm not a huge fan of doing this offsetting as that will realisticaly result in weird behavior if we change how settings are stored. Why is the FOV getting reset to the minimum value anyway?

[jvnpr]

eGameSetting_FOV doesn't store the actual FOV, but rather a value from 0-100 which corresponds to the FOV slider's position. A value of 0 just corresponds to the slider minimum, 100 to the maximum, etc. Since the range of the FOV slider has been changed, the slider's saved position corresponds to a different FOV. You can test this by moving the slider to any given position in the newest nightly and moving the settings.dat file to a build of this branch.

To prevent a player's FOV from being changed when they update, I added the conversion check to see if we need to convert their old FOV setting to a new one. The way I implemented this check is by changing eGameSetting_FOV to have an offset, pushing the range to (101-201). This means that we can check if the player's eGameSetting_FOV is below the new minimum, and if it is, apply a conversion factor to set a new equivalent FOV in the new system.

[codeHusky]

IMO there’s two better, sane fixes than offsetting the value for this particular situation. Either of these are probably good fixes.

• Add a “data version” value to the settings data file that we can increment whenever a breaking change is made. The previous value (or lack of it) can be used to inform conversion logic, including here.
• Create a new settings entry to replace the existing fov entry which uses a different identifier. The old identifier is ignored/removed going forward in a one way conversion

I’m not super specifically familiar with how settings are being serialized so it’s possible one of these is far easier than the other, but I’d much prefer this over letting magic number offset consequences trickle down deep into the codebase.

[jvnpr]

• Add a “data version” value to the settings data file that we can increment whenever a breaking change is made. The previous value (or lack of it) can be used to inform conversion logic, including here.

A data versioning system would probably be better for longevity, but instead of bootstrapping that system here I think it'll be better to break it off into a separate PR first before we implement this. I'll set that system up (should be straightforward) and rebase these changes on top.

[jvnpr]

I messed up some git things with this due to inexperience so I'm going to submit a new PR tomorrow with these changes built on top of the SettingFixer system (#1097). I have it marked as a draft for now and would appreciate your feedback.