Why do some video game and computer program graphical options have to be “applied” manually while others change the instant you change the setting?
In: Technology
It’s mainly a user interface design choice.
Many graphics settings affect or interact with each other. When adjusting settings, you may need to change several and then apply them all at once to see what the overall effect looks like.
If each change was applied independently the instant you made the change, then you wouldn’t be able to easily see the difference that your overall selection of changes made.
Applying the settings changes all at once makes it really easy to do an A-B comparison between old and new settings.
Another reason for the “Apply Changes” design choice is that it allows you to easily cancel. The pending changes are staged, and you can easily back out of them without having to reload anything. If the changes were applied the instant you made them, then they would have to be undone in order to “cancel” them, and you’d end up reloading twice.
It actually applies to a lot of design of both software and hardware. You’ll have some initialization you do on startup. As a designer/engineer/developer, the least amount of additional work needed to support modifying a setting is to just re-run that initialization process. As an added bonus, it’s less likely to introduce a bug, since that single initialization process can be tested more thoroughly.
Now, if you want to change individual settings and apply them individually, you have to break that initialization up into different sections. You have to pull out all the error checking/handling, all the consistency checks, etc. The amount of development goes up.
In short, it’s easier to check and apply everything at once. But the user experience is better if you can do things individually and see the results immediately. So there’s a tradeoff.
Usually is just a matter of developer’s preferences. Sometimes it’s a bit challenging to apply the settings as soon as they’re changed (e.g. in a video game where you have to reload objects while being careful to remember their state), sometimes it’s just not feasible (applying the screen resolution as soon as the option for it changes can be annoying for the user) but most of the times it is just a choice, applying settings as soon as they’re changed is a pretty new thing so many developers are used to do this via an “Apply” or “OK” button.
Think of the program like a workplace.
Sending out a memo for a price change is easy. You can do that during a workday. That is what it is like to change a simple setting.
However, asking all employees to change their uniform to a different one would require a significant logistics planning to perform while everyone is at work. It would require changing rooms, and rotating employees in. Unless you are fine with your business entirely pausing (program freezing) while everyone changes.
It is simpler in the second example to just send employees home with a note to come dressed differently tomorrow. Especially if the dress code rarely changes.
The clothes are the different variables/functions/resources that would need to be loaded to change an integral setting.
If you build a building, and somebody wants to change the pain or the windows it can be done after the fact. If you want the walls or support beams of the building made out of different materials the builders need to know *before* they begin construction. Each time you start the game it’s like constructing that building.
Some settings are paint/windows/decorations. Some settings are like the materials used to make the walls and support beams.
Correct me if I’m wrong, but I think some of these settings require that the engine to recompile its shaders, so this requires at the very least an “Apply” button. Shaders are these programs which compute how a pixel on the screen might look like. There isn’t one big shader program that would contain all the special effects at every detail level. Shaders are compiled during runtime, and are optimized to only render a set of special effects and at a certain detail level. Having to change these settings means that the compiled shader would be invalid, and it a new one has to be made for the new settings.
Some settings can be changed instantly because they’re usually just variable inputs to the shaders, so not much is changed.
Changing screen resolution needs to be “applied” because the monitor might not support the resolution, and cycling through the list while the resolution changes every time is not ideal.
On the other hand, changing the resolution of the draw buffer/surface/canvas can be done in real-time without any flicker. Some games like Monster Hunter World actually has a dynamic one that adjusts according to the average framerate.
Think of your house. When you want things brighter, you can flip a switch and a light goes on. Some game features are more like wanting a different bulb altogether. Maybe a softer color. For that, you need to turn everything off, and replace the bulb. If you spend some more money up front, you can get one of those bulbs that can adjust its color through an app, while it’s on! Game developers make trade offs based on how expensive it is to add a feature. Sometimes it’s cheaper to go with the “replace a bulb” way, if it’s something that doesn’t change too often — or if the “software controlled lightbulb” approach is too complicated.
The code that actually calculates and runs each of these different effects is quite complex, and they all sit together in even more complex chains. Certain effects can only be calculated after others have been done, and so on.
When you fire up a game, it will *generally* only load the code for the effects it needs, and chain them together in the most efficient order, based on what you’ve got set in the settings. Having the ability to change which effects are loaded once they’re loaded, and which order they go in, isn’t a simple thing – so some game engines can’t do it.
Thus, if you go into the settings and change which effects you want, and the game’s underlying code isn’t smart enough, it’ll have to save those settings, and load itself fresh from the start. Other engines are more sophisticated, and the developers have taken the time to allow these chains to be modified after being loaded.
I’m a developer who has programmed a game engine from scratch. The reason some settings can be applied instantly and some need to be “applied” is because of how it is coded. It takes extra work to develop a system that is able to change on the fly and still run efficiently. Also like others have said, it is much easier and safer (less likely to create bugs) if everything is wiped from memory and everything is loaded again with new settings.
Okay so you’re programming on Windows and you want to make a window with some buttons, text input boxes, checkboxes, [radio buttons](https://en.wikipedia.org/wiki/Radio_button), etc; a settings menu, let’s say. To make everything easy for the programmer and consistent across the OS, Windows provides these widgets to all programs on the system. An arbitrary program just needs to tell Windows “Put a checkbox with text label ‘Some String of Text’ at some particular place in this window”, and Windows takes care of how exactly that checkbox works (how it looks (animation maybe?), how it behaves (response to being clicked, text input, mouse hover, etc)). Then, a few lines down in the program, the programmer can ask Windows “What is the state of that checkbox I created a while ago?” and Windows will answer “checked” or “unchecked”. Or the programmer can ask for the value of a particular text input box and Windows will respond with the text contained in the box.
The programmer can also tell Windows stuff like “When this widget is interacted with in this particular way, run that particular function that I wrote”. So some programs just do that for every widget on screen, and save each change somewhere every time the user changes anything. Usually this is what’s going on when you don’t have to Apply or Save your settings. Each time you change a setting it gets autosaved right then and there. So when you’ve set everything how you want, just exit the settings window and you’re good to go.
But there’s a cost here. If the user is messing around with game controls, those settings don’t need to be updated in the game memory until the player starts playing again, so it doesn’t make sense to go through the effort of updating each setting each time it changes. And for some settings, like graphics settings, a lot of work/reloading has to happen in the background to apply your change. So it makes more sense to just have the user set everything how they want without their changes going into effect, and then give them buttons to actually enable all of these changes, with the understanding that clicking said buttons might result in several seconds (or, especially back in the day, minutes) of downtime while the game gets everything in order. The standard three buttons are “Ok” (apply changes and exit this menu), “Apply” (apply changes but stay in this menu), and “Cancel” (exit this menu without saving changes).
As computers have become more powerful and UI programming has become more flexible (at this point most games draw all of their own widgets instead of using the OS widgets), programs and games have started moving to autosaving by reacting to every UI event, and only use the Ok/Apply/Cancel scheme for things like changing graphics settings, since there’s no getting around that momentary black screen, or the possibility that the new settings will be completely unusable on your screen.
Latest Answers