Similar issue to #5966.
This now provides a way to ask the option for its value instead of relying on a side effect assignment.
At the same time, this is now cached for set-once options, allowing for fast querying.
Furthermore, it gets rid of some really really ugly code throwing around raw pointers and kind of illegally managing memory in favor of shared_ptr's, as there's a good chance that that was part of why the compiler mis-identified the optimization in the first place.
Should fix #6344
This should probably be tested in release mode by someone with an MSVC compiler.
To be frank, this is a hotfix only.
A more permanent refactor of the ingame options will be needed for 25.0 to a) optimize lookup performance, while b) not relying on side-effect access to variables that the compiler can mess with. Options should store their state fully internally, not giving a user access to the data outside of the option object.
Similar issue to #5966. This now provides a way to ask the option for its value instead of relying on a side effect assignment. At the same time, this is now cached for set-once options, allowing for fast querying. Furthermore, it gets rid of some really really ugly code throwing around raw pointers and kind of illegally managing memory in favor of shared_ptr's, as there's a good chance that that was part of why the compiler mis-identified the optimization in the first place.
Should fix #6344
This should probably be tested in release mode by someone with an MSVC compiler.
To be frank, this is a hotfix only. A more permanent refactor of the ingame options will be needed for 25.0 to a) optimize lookup performance, while b) not relying on side-effect access to variables that the compiler can mess with. Options should store their state fully internally, not giving a user access to the data outside of the option object.