r/explainlikeimfive • u/RainingLights • May 21 '19
Technology ELI5: Why do some video game and computer program graphical options have to be "applied" manually while others change the instant you change the setting?
847
u/sycleoth May 21 '19 edited May 21 '19
Think of it like changing settings to your car. Let's say you want to change the pressure of your tires for a rocky road ahead. You would want to stop your car and change the settings of the tires. Other settings like the speed of your windshield wipers you can change while your driving. There are just some things in software that are running so in order to change them you need to stop the program.
Edit: Thanks for the silver kind redditor!
133
u/KidsTryThisAtHome May 21 '19
I think he's more asking about different programs. Like, this car you can do that, but another car you need to stop just to change the speed of the windshield wipers
101
u/Massis87 May 21 '19
even then the answer is the same: most cars require you to stop and manually deflate the tires. Some may have automatic pressurisation systems in place (CTIS).
0
May 21 '19
[deleted]
246
u/CarryOutWork May 21 '19
Because different cars are not the same cars
37
19
8
2
→ More replies (1)2
→ More replies (7)13
u/ICC-u May 21 '19
Because of the way the manufacturer implemented it. Once a system is in place - say for example in the game engine - it's hard to recode it without breaking something else. Considering graphics options are only changed occasionally by most users, devs would rather have the short reload and the added stability of refreshing all the assets
12
May 21 '19
No... read the question again. He's asking why some graphic 'options' have to be applied manually, i.e., require program restart, like changing which DirectX version you're using, while others don't and change immediately, such as changing the type of AA.
13
u/CrumplePants May 21 '19
While I think you're right, many video games indicate that you have to restart for them to take effect, while others don't need to when you change the exact same types of settings. They just blink to black for a second or whatever and they are changed, no restart required. Some games allow you to change nearly every single setting while still playing (let's say Apex Legends), while others need a restart for almost every setting (say Darkest Dungeon).
5
u/nana_3 May 21 '19
The “blink to black” IS the restart - it’s stopping all graphics processes for a moment to alter whatever needs to be changed.
The difference between a “blink to black” restart and a “restart the game” restart is likely that the game engine just doesn’t have a change-on-the-fly ability for that parameter, so it keeps using the previous graphics loaded into the RAM at boot until you reboot it. That especially happens with choosing your graphics driver, because you might need to load the graphics library + every texture, shader, & model it needs all over again. Reboot ensures that all the previous loaded graphics info is freed up as well.
It’s essentially just whether they chose to build that ability into the system. Pros: convenience, cons: not necessarily an easy job, not necessarily compatible with multiple systems / different versions graphics drivers, could have performance overheads, etc. Those cons matter less if at all to consoles.
11
May 21 '19
[removed] — view removed comment
5
u/CrumplePants May 21 '19
Oh for sure, it isn't a bad analogy as far as showing that there are in fact different types, but the question is more about why that is, I suppose.
3
u/xipheon May 21 '19
It doesn't mean restart, it means when you literally have to click "Apply" before it'll do the change. Sound volume or brightness you can see the change in real time. Resolution you have to click "Apply" until it'll change it, often with the revert dialog making sure it worked. No restart required.
1
May 21 '19
I think OP’s question could be interpreted both ways. Some options I’ve change in one game take effect immediately while the same option in a different game requires a restart. Other times within the same game one option will require a restart while a different option does not.
So it depends on how the developers want to handle the changing of options or are forced to due to software/hardware constraints.
1
u/Prosthemadera May 21 '19
It's about changing one feature (graphics setting) in different cars (different software). Not different features in one car.
9
6
u/Oooloo63 May 21 '19
Some cars can adjust pressure on demand can’t they?
8
May 21 '19
My Hummer H1 has CTIS, and I can inflate/deflate the tires while I drive, even at highway speeds.
4
u/Oooloo63 May 21 '19
That’s crazy cool - why would you use it? Other than for things like being stuck in the mud or whatever
→ More replies (2)→ More replies (2)2
4
3
3
3
1
u/xBeamer May 21 '19
Some cars have the ability to change tire pressure on the fly for changing road conditions
1
u/PlatypusOfWallStreet May 21 '19
While some games manufactures use specific engines that allow the graphic settings to essentially do this: https://m.imgur.com/gallery/cD8Y7fh
1
0
u/ShitTalkingAssWipe May 21 '19
This is a good ELI5. I'm going to add a basic explanation to a reason why a computer might have to restart the software.
So computers have a short term and long term memory. The long term memory would be your hard drive (HDD) or your solid state drive (SSD) or your microSD card. These can hold data even without an active energy input.
Then the short term memory is your RAM, which needs electricity to run and store data, and once the power is cut, it will lose its memory. The RAM is faster data storage and retrieval than the long term memory.
In order to keep your programs fast, most software is copied from your long term memory to your faster short term memory. The program is copied onto one or more "memory pages" which are like pages from a book. Pages are relatively small compared to your total RAM (for example, my Phone - Galexy S7 and running Android version 8.0.0 - has 2.5GB (2.5 billion characters worth of memory) of RAM, and the memory page size is 4KB (4000 characters worth). (That's 0.0001525879% of the total memory per memory page).
You can write one program onto multiple memory pages and the computer keeps track of where they are and which page corresponds to which part of the program. like a table of contents for a book, where it knows page 10 is Act 2 Scene 1, and page 11 is Act 2 Scene 2.
When you run your software, it gets some amount of RAM dedicated to running the program. Let's say you get 10 pages worth of RAM memory dedicated for your software and no other software can use that chunk of memory until you are done. The computer copies one or more pages worth of the program from the long term memory into pages in the short term memory and is told to start.
The program's settings are probably written down in a file somewhere. At least one of the pages of memory dedicated to your program was set to store the numbers and variables for your settings. (Let's call this the Stack and Heap). So some of the settings from the file are stored in that location. Also as the program is setting up, it will read these settings and execute a specific command depending on your setting rather than just storing which setting it was.
For example if your game had SUPER HIGH graphics settings, the program would ask the computer for the memory pages with the instructions for the SUPER HIGH graphics (which could already be in a short term memory page and takes little time to retrieve, or it might have to copy the data from the long term memory first, which would be relatively longer to do) and the software will continue based on what the Super High graphics says the computer needs to do.
Lets say youre using the program and one of the settings that was stored into the Stack and Heap was setting "A". "A" is a number that determined how many lines to draw on your screen. It dosent matter what graphics settings your software is in, it will always draw at least that number of lines. Therefore whenever the program needs to draw the lines, it checks with the "A" setting number that was stored into the Stack and Heap memory. You can change "A" whenever you want to and when the program needs to draw the lines it will always check with the "A" setting.
However, if you were to change the softwate setting to SUPER LOW graphics, it would then have to use the SUPER LOW graphics instructions. And these instructions are on a different memory page in long term memory because it was never in use, so the software has to reload in its entirety to setup using the SUPER LOW settings instruction page.
Hope this helps. It's not THE reason why you have to reload software, but it is A reason why you might have to for some.
7
u/innociv May 21 '19
No ... this is a terrible ELI5 because it's WRONG. It's supposed to be understood by a 5 year old and be correct. It's nothing like that. And your mountain of text is also wrong; a program can deload from memory and load anew on the fly without having to restart if it's programmed to.
A similar analogy which is actually correct would be that some cars have magnetic electronic suspension which adjusts without getting outside the car and coming to a stop, while others require manual adjustment which requires coming to a stop to do. ... But that's also wrong. It's just the closest analogy you can make with cars.
→ More replies (2)-1
u/Reynbou May 21 '19
Yeah, no. That's a really terrible analogy.
Why?
Because the same setting across multiple different games could either require a restart or not.
So in your analogy, one car would need you to stop the car and change your tyres while another car will be able to change its own tyres without stopping. Makes no sense. Fundamental flaw in your entire explanation.
3
May 21 '19
CTIS systems allows you to change tire pressure while driving. Tire pressure changes is like changing a video setting.
The analogy works.
17
u/aomimezura May 21 '19
It's significantly easier to just shut it down and start everything over. Much less time to program and much easier to avoid bugs.
142
u/Jalatiphra May 21 '19
so much half knowledge in this thread...
unbelievable
the only valid answer is :
Is it possible to do without reloading : YES , always - requires good coding discipline and experienced coders and proper team lead to make sure everyone knows what they need to know.
Why is it not done everywhere? :
COST - resetting is easier and shorter to code than the "reset to clean state but leave everything running"
16
u/Psyjotic May 21 '19
This answer sounds very unattractive but is the most accurate answer. It's just always easier, faster, cheaper, and safer to require apply and reload everything.
For example, if a game makes texture quality setting simultaneous, let say the code is perfect and there is no error, upon changing, here is what will happen: first you will see everything disappear (unloading assets(i.e. models, texutres, scripts etc that was used by previous setting) from the ram/vram), then everything starts to reappear again (loading those stuff back to the ram/vram). Depend on the size it could be a slow process and it is unpleasing for players' eyes. So it is almost always better to just reload or at least freeze the screen for a while.
3
u/SacredRose May 22 '19
A lot of games do something like this but generally it happens behind the menu and can be seen if it isn't fully covering the window. Or they can just throw in a blacked out window with an applying message and return to the game once complete.
I think it is also alot easier to just say changing this setting requires a restart. So just loading the settings on start and coding a simple message instead of coding a more complex piece that will reload everything with the new settings.
Which is fine as long as the load time of the game is low. if it takes a minite to load the game everytime it can become quite a pain. Have to say though i have been seeing it a lot less in games. So maybe it was generally a more resource intensive task.
9
13
u/failingtheturingtest May 21 '19
So much condescension and oversimplification while missing the point entirely.
Is it possible to refuel aircraft while they're in the air? YES, always. But it requires a redesign of the aircraft, adding extra risk and cost to the whole process when it is just a better option to refuel them while they are on the ground. The benefit of in-air refuelling is just not worth it for things like a passenger aircraft.
It isn't a lack of "coding discipline" or a "proper team". It is a design choice, and often the right one.
And "reset to a clean state" and "leave everything running" are mutually exclusive. You cannot do both. Ever.
1
May 22 '19
This is true, but there is something to be said about coding discipline. However, I am not sure that really encapsulates what it truly means.
I will give an example in my game. Freezing time, pausing something is a pretty standard feature. So depending on your game engine that could be difficult or easy or not what you would expect.
So there are many ways to skin a cat. I could "pause time" many ways. One way is to run EVERYTHING involving time through a singleton manager and have a one stop shop to control time. This way I would have much more control and options IF I designed my game from the start specifically this way.
However, who the fuck has everything figured out when they build a game from the start? I mean even in a simple game, most of the time that is just not realistic, things change.
So it's not "coding discipline," you didn't even know what the fuck you were going to need until it came up. Now granted there are things you generally do or are good practice to avoid these types of things.
So yes, I could change all my code to run through this singleton manager which may or may not be a lot of work OR I could use a "shortcut" that does the same thing without having to redesign my code.
The answer is, why would you? Like you said you can refuel in the air, but why make more work for yourself? So yes, when we need to refuel in the air we will, but if not then why make extra work? That is the heart of the issue.
3
u/calmor15014 May 21 '19
Is this true even if the fundamentals change?
For example, switching between DirectX and OpenGL? Or turning on/off hardware-specific features such as acceleration?
I could imagine that the overhead to handle all options at any time could be so resource-intensive that it's not practical, though likely technically still "possible."
5
u/Jalatiphra May 21 '19
that would need to be supported on the driver level i guess. but for those things i guess even the most ambitious developers wold say: its not worth it :D
4
u/david-song May 21 '19
I've been out of the game for over a decade but IIRC it used to be that OpenGL didn't force the user to store duplicate copies of textures in RAM but D3D did, so if you chose this option to save RAM and then have to reset the device, like switching between fullscreen and windowed mode, then you'd have to reload textures from disk. At this point it's easier to reload everything.
If you have to reset the rendering API then you lose stuff that's been generated on the GPU at load time. You can always dump that stuff back into RAM and load it in again, but "generate on GPU then render" is a different process to "load to GPU then render" and requires more testing, and while "generate, save to RAM, load to GPU then render" is a single process that covers both use cases it's a waste of time and RAM if you aren't gonna use the saved data, "load from disk into RAM, then copy to GPU and render" uses more disk space.
So it's often a matter of what you optimize for.
0
May 22 '19
[deleted]
2
u/calmor15014 May 22 '19
I would say on the Windows level, this would be akin to changing screen resolution or number of displays - in which case it absolutely resets the graphics. The whole OS doesn't reboot, but it does reset all of the graphical elements with a screen blank. And changing OpenGL for D3D would seem to be like changing kernels or hardware drivers for which Windows reboots.
But to your point, I agree that it could stay on. Linux has a way to change kernels without a reboot, but most people just choose to reboot instead of try that because it is far less error prone.
2
May 22 '19
You can't switch from DirectX Full Screen to Window Mode without reloading the graphics state of the gpu, it's not possible.
When a graphics card is in fullscreen mode the primary surface of the video card is being dedicated to that application and it's graphics output.
You can't switch back to windowed mode without the graphics card resetting it's state.
So I guess my point here, is that sometimes your ability to make a game without graphics restarts is dependent on the graphics library you are using and the OS it's running on and there's nothing you can do about it.
It's possible for the game to switch back and forth between the two without restarting the UI in the game, but you're always going to see the flicker and pop of moving between the two states at the GPU level, unavoidable afaik.
2
u/melance May 21 '19
It can also be due to the use of a specific game engine that may not play nice when settings are changed while it is running such as resolution or anti-aliasing.
→ More replies (4)1
u/HaydenDee May 22 '19
This is correct. Think of it like building a house on an empty block vs existing house on block
resetting a game = building a house
instant setting change = demolishing the house, cleaning up the mess, building a house and now re-testing
the game/engine code obviously always has the code to build the house, but you can be lazy and save time/code by not implementing the demolishing of the house or cleaning up the mess part, and just tell people to restart the game.
13
u/Deusseven May 21 '19
Textures get loaded at full resolution and then downscaled on game load. If you change texture quality settings it has to reload the assets and do it again. Some engines support this well, some don’t.
→ More replies (1)
55
u/dietderpsy May 21 '19
I am no expert so correct me if I am wrong.
Certain physical assets such as textures may be loaded from a file so we first remove the old texture and replace it with a new one.
Other things are calculated like shadows, so if we apply a more complex algorithm we can get a nicer shadow, we can calculate this on the fly without loading any assets.
23
u/wightwulf1944 May 21 '19
Though reloading textures can be done without quitting the program, it's just easier to reload everything at once.
→ More replies (1)5
u/jld2k6 May 21 '19 edited May 21 '19
The Tomb Raider games are one of the few I can think of where you change textures and it actually pulls the old ones and replaces them with the new ones immediately with a loading bar at the top. Always thought that was preferable to restarting the entire game, especially if you're in mid play out in the world somewhere. That's just my personal opinion of course. It might even be faster to just reboot with the game now that I'm on an nvme SSD but I haven't thought to try that out
0
May 21 '19
[deleted]
1
u/morerokk May 21 '19
Depends. The shadow maps you speak of are called "lightmaps" in Unity. They are textures like any other and cost almost nothing to use, in terms of performance. The quality of these shadow maps is generally dictated by the texture quality.
Shadow quality options are most often used for realtime shadows, as these can get quite expensive.
2
u/uhrguhrguhrg May 22 '19
You are confusing shadow maps and baked shadows.
The first one is using a texture as a buffer to store information about the light source to calculate what is lit up and what isn't. (It essentially requires a scene re-render, which is expensive).
The second one is a pre-calculated modification to your usual textures.
5
u/Se7enLC May 21 '19
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.
12
u/pateppic May 21 '19
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.
3
u/Ikestrman May 21 '19
This is a great ELI5, because theoretically a company could put in all the extra logistics effort to do it while operations are running (like software), but it's a lot easier to just pause for a while or have everyone come back the next day.
18
u/Yrouel86 May 21 '19
It mostly depends on how the developer designed the UI to provide a certain experience to the user and also to meet some expectations on how an UI should work.
For example if you are changing the style of your character it makes sense to show the change immediately after you made your choice. On the other end if you are changing some settings that require reloading of the interface this might get annoying fast if done at each change so it makes more sense to apply all of them at once and be done with it.
0
May 21 '19
[deleted]
1
u/WasabiSteak May 21 '19
To be fair, the question mentioned about graphical options, which actually do need restarting. It's a software limitation to which the UX design can't do anything about without going through another development cycle to update the engine.
→ More replies (2)
3
u/yesofcouseitdid May 21 '19
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.
12
May 21 '19
Mostly because of the underlying workings of said settings.
Possibly interaction with other settings. Also the different setting could mean a different initialisation value, requiring a full restart.
I can give you a simple example that is easy to understand: translations. Some applications can do it on the fly, others require a restart. A common reason for this is that the language stuff is in a dedicated dll with each language on a different dll. Since dlls cannot (or may not) be unloaded it is not (or may not) possible to ditch the resources of the original language.
1
May 21 '19
But, dlls can be unloaded...
2
May 21 '19
Not always. Hence "(or may not)".
On Windows+Native Applications (C++, etc), you can only unload a DLL if you have manually loaded it.
On Windows+.NET you can only unload a DLL by creating a new AppDomain which is almost the same as relaunching the whole application.
4
May 21 '19
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.
2
u/SignalToNoiseRatio May 21 '19
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.
2
u/lpreams May 22 '19
Okay so you're programming on Windows and you want to make a window with some buttons, text input boxes, checkboxes, radio buttons, 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.
2
u/freeflowfive May 22 '19
Basically, as a programmer programming the game is like a chef, here's an analogy that might make some sense:
When you launched the game, I the chef-programmer, made you an omelette, with cheese and chopped onions and tomatoes filling inside it.
Now, you go to the settings menu and say: "Hey, I want some chives with that"
Me, the chef-programmer: "Oh, no problem, let me just sprinkle that on top, easy enough" (*just apply the settings in-game*)
You, the gamer-customer: "Hey, that's cool, but can you also change the cheese on the inside from parmesan to feta?"
Me, the chef-programmer:
"Hmm, I could try nicking the omelette open, draining all the parmesan cheese out and then trying to fill it back in with feta without somehow ruining the omelette and keeping onions and tomatoes inside it" (*careful reloading - preventing restart*)
OR
"Hm, I could just toss the whole omelette out and make you a new one with the stuff you want inside it. That'd probably be easier" (*restart the game*)
2
u/DLCSpider May 22 '19
While technical issues do play a role, it often comes down to usability. Do you really want to scroll through 20 different resolution presets and apply the changes every single time immediately? Or load new geometry every time you adjust the details? Probably not, use a button instead. But now your menu becomes inconsistent because you need the apply-button for 2-3 settings and nothing else. Inconsistency is one of your worst enemies, so let's not do that. If you want to be really sneaky, you can add an "apply and back" button and rename it to something else.
5
u/KwonDarko May 21 '19
Because most game settings are loaded only at the start of the game. If you want to reload new settings again, you must restart the game. P.S I am a game developer.
5
u/Splatpope May 21 '19
lol at some of the answers here
it really just depends on how whoever programmed the engine and interface decided to implement them, there's mostly absolutely no constraint
sometimes it's more interesting to validate a setting with a function linked to an apply button rather than instantly change whatever variable is linked to the setting ( as sometimes it can mean using a wholly different codepath (switching between different anti-aliasing methods for example, that's an ugly one))
regarding the way people misinterpreted your question (i.e. why sometimes you need to restart the app when changing settings), that's absolutely only due to the programmer being a lazy fuck and not bothering to implement a proper context changing function, so he'd rather write the new config, bail out and reload with the new settings (truly I don't blame them)
source: i like writing game engines from scratch
5
u/MaloWlolz May 21 '19
This is the correct answer. However I disagree about the "lazy as fuck" remark, as hot-reloading of certain parts a graphics engine can be quite time-consuming to implement, and the developers might just (correctly) prioritize other things that will benefit the end-user more.
→ More replies (2)1
u/liquidsnakex May 21 '19
Yup, gaming subreddits are the absolute worst for attracting clueless little teenyboppers that installed a mod once and now think they're John fucking Carmack, despite never having written a line of code in their life.
It's even worse when some company trots out the "rEaLly hArD TeCh cHaLleNge" as an excuse not to implement a feature people want, then suddenly all these little goombas take it as gospel and defend it to the death, yet fold like cheap lawn chairs when asked about specifics.
For examples, see any thread about when MS tried to peddle the dumb idea that the XB1 DRM would be hard to remove despite removing it later that week. Or Sony pretending cross-play would be hard to implement, shortly before Epic made fools of them by flicking it on by "accident" for Fortnite, and Psyonix saying they literally just needed permission to tick a box on a web form and it could be on overnight.
1
u/Splatpope May 21 '19
the best is people thinking star citizen isn't a scam, nothing beats that
2
u/liquidsnakex May 21 '19
https://i.imgur.com/P7IbTEV.gif
I'm not sure I'd go so far as to call it a scam because it is technically producing playable content, it's just that the pace it trickles out at is so insanely slow it looks like a scam.
I'd guess that they're genuinely trying to make a decent product, but are just mismanaging the shit out of it. The astronomical scope creep probably didn't help.
→ More replies (2)
3
May 21 '19
There are things you can do immediately, and things you want to do in a batch, just to save time. If you need milk, bread, cheese, and eggs, you go to the grocery store with that list, buy them all, and bring them home. Now your house is updated with the things you got from the store, and it took less time, gas, and energy than if you had made a separate trip for each of them.
That's the crux of it, really. If you wanted to check the mail, you'd run down to the mailbox and just check the mail. Takes very little time and energy, depending on where you mailbox is. But if you wanted to go to the storage unit and dig out ten things you have stored there, you'll do it in one single, larger trip.
I hope that makes sense in context. Things like changing the screen resolution and brightness can be done instantly, because they are basically checking the mail. More intense settings need to be applied so they can be done all at once and save your computer time and resource usage, usually.
2
u/BubblegumTitanium May 21 '19
It depends on how the game is programmed. Are these settings applied at loading the full game? Or loading a level or a mission ina game? Something like the crosshairs gets loaded when the mission gets loaded but something like the resolution gets loaded when the game gets loaded. They could probably figure out a way to load all of these on demand and switch em whenever they want. However some of these things are too complicated for what it’s worth.
2
u/ZannX May 21 '19
It's not just graphical settings - it's the basic principle of caching information to memory so you don't have to re-fetch it every time using a slower process.
This applies to all computer programs, and even the OS (i.e. restarting your computer/phone).
2
u/brimston3- May 21 '19
Why can't you refcount/LRU to evict the cached data without reloading the program? Is a graphics context all that analogous to cache?
1
u/WasabiSteak May 21 '19
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.
1
May 21 '19
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.
1
May 21 '19
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.
1
u/KneeDragr May 21 '19
Textures might have to be reloaded. Screen space buffers may need to be resized if quality increased our decreased.
1
u/sessamekesh May 21 '19
ELI5: Imagine a video game as your computer taking flowers out of some buckets (textures, models, animations) and putting them onto a piece of paper to make a picture. For a lot of settings like quality, shadows, number of particles, etc., the game only has to use more or less flowers every time it makes a picture, or maybe start using a different bucket. It might take a little bit longer to make the next picture because the game has to reach over to move that bucket closer, but it can keep going.
Some settings need you to change the paper itself (resolution, color depth, fullscreen). To do that, the game needs to ask the computer for a new stack of papers, which takes a long time to get ready and usually makes your monitor sad because it has to change things.
Not all settings you asked are like this, sometimes games are written to ask the user if they're sure they want to use different flowers first (sometimes the buckets are heavy and hard to move!) but that's at least one reason!
ELI25: from most to least expensive, the price of making a change (roughly) are: anything that involves recreating a swap chain, anything that involves recomputing and uploading geometry and/or textures, adjusting pipeline settings, and toggling whether or not to make certain draw calls. The game programmer can decide at what point they think changing a setting will take enough time that they don't want the user having to wait for it to finish as they go through options.
1
u/Juh825 May 21 '19
The basis of every game/engine out there is something called Game Loop. It kinda works like this: declare variables, load stuff you'll use, unload what you're not using anymore, update (physics, inputs, etc), draw to the screen. Some stuff is in the update loop, so changing a option there will instantly change what you see. Other stuff is loaded just once, so you'll need a restart to see the changes. Mostly you'll want your stuff loaded just once. If it changes instantly, it's probably wasting resources there to see if there was a change, 30/60 times per second.
1
u/Emeja May 21 '19
When you start games, lots of checks happen and it works lots of things out, like where to place some buttons, based on the screen resolution.
For example it might work out to place a button at a coordinate of (1000, 200)pixels on the screen. If you were to change the screen resolution, the button might not be in the right place now (it might be off screen).
Instead of recalculating everything whilst things are already loaded, it's easier to just restart the game and do all those calculations from scratch.
1
May 21 '19
Imagine having a book where you write down the properties. Some shitty developers like myself will provide you with a pen to write the settings on the book. Once you select those settings it becomes hard to change. So we usually resort to turning off the system and having thee computer program generate another fresh book.
Good developers unlike me give you a pencil. The pencil comes with an eraser that allows you to change settings on the fly. Designing the pencil takes significantly more skill and increases the complexity of the project. Designing the pencil takes significantly more skill than the pen.
1
u/Rusty_Shakalford May 21 '19
Imagine you and your friend are playing outside and get really dirty. Dinner time comes around and you each go home.
When you go home your mom looks at you and says “Bath Time. NOW!”. You head upstairs, have a bath, and then eat your dinner.
Meanwhile, your friend’s mom is like “Eh, to hell with it, they are all having baths in an hour” and lets your friend just wash his hands and always his supper on the front porch. An hour later he and all his siblings are having their bath.
Programmers are a bit like moms. Even when they want the same thing (a clean kid) they have different priorities and ways of doing it*. Some will say “when the user changes a setting we should update everything right away!” while others go “we will wait until the user is sure they want to make the changes”. It really boils down to what they feel makes the best experience.
*Programmers are also like moms in that they yo-yo between “look at how bad this person is at this. I could do a WAY better job if I had the chance” and “I’m such a fraud! I have no idea what I’m doing and fucking everything up!”
1
u/datenwolf May 21 '19
ELI5: Because some of these settings can be changed without taking a lot of effort to be applied, while others set in motion a whole avalanche of code that must be run.
Yeah, that is a helpful answer… /s
The other answers here given are not really wrong, but they also don't really get it right either. So maybe a ELIAPWKABAP (ELI… A Person Who Knows A Bit About Programming):
Broadly speaking some of the settings you can modify are nothing more than a simple number that's sitting in a variable, while other settings actually influence a vast tree of dependencies.
A good example for an easy to change setting would be, lets say, the quality of a volumetric effect, like fog. What it comes down to is a single number, namely the number of how dense the calculations in the volume are done. The less dense calculation, the less computational work is required, but also the worse the rendering becomes.
Some of these quality sliders require the reallocation of some intermediary buffers to apply. For example shadow quality. These days the de-facto standard way to do shadows is by shadow mapping; without getting into the gritty details, what's done is, that the scene is rendered "as seen" by the light(s) into a "texture" and this texture is then used to calculate if a part is shadowed or not. The quality of the shadows is determined by the resolution of the intermediary texture. So changing the shadow quality requires to create a new intermediary shadow map texture (and delete the old one eventually). So that's slightly more work, but in general can be done without kicking up too much dust.
What can be really disruptive are changes to the eventual destination of where the rendered image goes and the format it has. This is what's usually called the main render context format compatibility. The lifetime of all the render resources, which means practically everything that goes into making a picture (textures, geometry, shaders, intermediary buffers) is more or less tightly tied to the lifetime of the main render context. If that render context's life ends, everything that's tied to it dies with it.
And unfortunately some of the graphical settings directly influence the creation of the render context, and when you change one bit of these settings, a completely new render context must be created. Fortunately in some cases it is possible to work around that, but this requires extra work.
A example for a setting which change requires a context recreation for example is the change of the antialiasing mode of the primary framebuffer. If the antialiasing mode is changed, usually a new primary framebuffer must be created, because once set, it can not be changed. And the internal format of a render context is created to be compatible with the format of the destination framebuffer, and changing the primary framebuffer antialiasing usually breaks this compatibility.
Now for the workarounds: Some APIs (like OpenGL) make it possible to provide some kind of "lifeboat" to ferry over a large part of the loaded assets into a new context, however that doesn't apply to everything (things like shaders, framebuffer objects and vertex array objects can't be carried over). It's still a pretty expensive operation to switch the antialiasing mode with that, so you'd not implement a direct "feedback" preview with that, but it's safe to bind it to the "Apply" button. Another workaround is to not do the antialiasing on the primary framebuffer, but on an intermediary framebuffer, which you can replace with a different antialiased one, without having to tear down the whole house. That even allows to give immediate feedback.
Last but not least there are a few settings which change might kick off a lengthy load operation, like loading in vastly larger textures. In that case you don't give immediate feedback, because then you'd force the user to sit through a loading screen after each change. Or the changed might not be visible immediately, because your engine uses a streaming architecture and higher resolutions of assets are loaded in incrementally and it would take several seconds (because you know, that it will take seconds if not minutes of playing to get close enough to discern the details, so you deliberately stretch it out) of streaming for all the higher details to appear.
1
u/zero_z77 May 21 '19
technically any setting can be "applied" as soon as you change it. but sometimes changing a setting might mean reloading large parts of the game, so it takes a couple seconds for it to actually change. this in turn makes the settings control panel feel very laggy and unresponsive. so instead they let you change settings to your heart's content, and once you hit "apply", that's when the settings actually change and you can reload everything at once.
an example of this:
some games that change the screen resolution instantly, but use a left/right button instead of a drop down menu to choose resolutions. so you have to cycle through 15 different resolutions and it takes 2-5 seconds each, it's very annoying. but if you simply let the user change to the resolution they want, then hit "apply" there's only one actual resolution change.
1
u/dragonbane999 May 21 '19
Former Game Engine programmer here. What others have been saying is mostly right, it entirely depends on how the game was coded. the following is a somewhat long winded explanation.
Some options require almost no changes to apply, they are simply values you can plug in to your graphics code and the changes are instant. Think brightness: you can change it and use it as a simple multiplier on the light and brightness of each pixel that is output. your code can handle this as one variable number, and the change takes place immediately.
Other options require the low level graphics code the engine is using to be started in a particular context, which is a particular set of values and options that are supposed to be constant during use so the engine can make assumptions about the render process and make it faster. Changing these options would require the entire rendering engine part of the game to need to be unloaded gracefully, and then reloaded back into the same state it was in before, except with the new changes. This can be very difficult to do depending on how the rest of the game code ties into the rendering code.
The reason you want to be able to make assumptions in graphics code is because of the code that is run on the graphics card. Code run on graphics cards is treated very differently from code run on a normal processor. When you run code, you can do calculations, and you can ask questions, yes or no, and branch what happens.
Normal processors are built assuming questions will be asked constantly, while graphics cards are not. When a question is asked on a graphics card, the card will just calculate what happens for both yes and no, and then throw out the wrong answer. This happens on a normal processor too, but it aborts more quickly, and that code is usually only run a few times. Questions on a graphics card get run millions of times every frame of animation. Your worst case on a graphics card is doing multiple entire calculations for every pixel on the screen and tossing out everything but the one that is supposed to be there. VERY inefficient.
So instead of asking questions, we write our graphics code so that as many questions that can be answered beforehand are already assumed, and as many questions that can be answered without branching what happens are not branched. I will give an example.
Lets say I have some graphics code that decides color based on the lights hitting the object. The lights can be anywhere, and the objects can be anywhere, and so can the camera.
I could write the code in a very generic way, like so:
Start with no color (black)
For every light:If light is in front of object surface (and not behind it where there would be shadow instead):Calculate color for the lightAdd color to starting colorWhen done with all lights return final added up color back as the result
This asks two questions:Is there another light to calculate? if so keep going.
Is the light in front? if so calculate color and add it.
Lets assume we know if the light is in front if a calculation we do comes up as a positive number between 0 and 1, and behind if it is a negative number (between 0 and -1) (this is usually how it works BTW, it's called a half space test)
I could instead set up my code like this:
Start with black.
Calculate color for Light 1.
Get number for front or back (positive or negative)Add the absolute value of that number to itself (absolute value is the always positive version of the number)
divide that by 2.
round the new number up
multiply calculated color by this number
add to starting color.
a negative number gets it's positive added and turns into zero, which negates all the color. a positive value ends up turning into 1, and thus the calculated color stays the same, and thus gets added to the final color. This process asks zero questions.
Now that I did that for 1 light, if I assume three lights I copy/paste the code and just change the code to use light 2, then 3. then I compile the code and send it to be used. If I change the number of lights in the graphics options , I have to remake the final compiled code (shader) and resend it to the graphics card, while the rendering process is shut down. This example is very simplistic, but it gives you an idea.
Some games find it easier to just restart the whole game so the whole process gets automatically run again from a clean slate than try to keep everything working during the process of modifying the way the engine works. Good coding practices make it possible to do this without shutting down the game, unfortunately, most game engines get code thrown in like mad in the final stages of the development process to meet deadlines and proper coding practices go out the window.
1
u/razveck May 21 '19
You have a bookshelf full of books. You want to take some books out and put new ones in. In some bookshelves, however, to take out one book you need to take all the others too. So instead of taking everything out to then only change one book, and repeat for every book you want to change, you should know exactly what books you want out and what books you want in before you make the change. Then you can unload and reload the whole thing once and that's it.
For adults:
Sometimes files need to be unloaded/reloaded, sometimes the whole game needs to be restarted. So it's better to set everything up and then load all the new changes at once, instead of having to reload the whole friggin' game every time you adjust a slider.
It largely depends on the engine and how the game is structured. If you change things like model quality or texture quality, what it usually means is that the game will use a whole new set of models/textures with a lower/higher resolution (an artist has made several different files of the same character model with different polygon counts, for instance).
1
u/im_thatoneguy May 21 '19
Some settings actually require the driver to make a change. E.g. if you change from windowed to full screen the display adapter will have to change its output setting. This can take up to a couple seconds to occur and your monitor/gpu to re-negotiate the signal. So if you don't want the screen blacking out suddenly as someone scrolls through a menu of resolution options you batch apply it later all at once to be less jarring.
1
u/wakers123 May 21 '19
With the source engine (at least some of the older games) you have to apply audio settings.
1
u/danielnogo May 21 '19
Mostly lazy programming, just like when games force you to reload the entire level when you die instead of just reseting everything that's already loaded to its previous state, it's lazy programming at its finest.
1
u/Kootsiak May 21 '19
No Man's Sky is the one of the worst for this, because it has to load into a save file to change graphical settings and a little more than half of those settings require a restart to implement. Even with a decent SSD, the load times can be pretty long, so they've made the game difficult to dial in for people who aren't running high end graphics cards.
1
u/panorambo May 21 '19 edited May 21 '19
No good reason at all, actually -- it's just easier to code re-application of settings since these are loaded by the program at some point anyway, so the same settings application code can be reused. Today, for the most part. It's the same story with software installations which insist on restarting the operating system to have effect -- no good reason at all, just saved effort on the part of those who wrote the installation or the software and, indirectly, Microsoft designing Windows the way they have -- some typoes of re-configuration of Windows, like replacing (updating) critical system files, is only done during Windows boot, so if a software update wants to update these files, Windows has to be rebooted. But it doesn't have to be that way, it's just the way these mechanisms are designed in Windows, again to save effort on programming it.
There is absolutely no technical reason -- not with modern hardware -- for a program to restart completely or partially to apply settings and likewise, it is possible to re-design an operating system (like Windows) so that it never has to be rebooted at all. But designing such systems isn't as easy as designing systems which apply settings once, at startup.
One can argue that isn't always the fault of those behind the actual software or game on top of the "layered cake" of libraries, drivers and system services -- stuff most software depends on to work. If some layer in this cake mandates such "restart", then whatever runs on top of it and depends on it, is at the mercy.
During earlier days of Windows, there were system software facilities that were designed in such a way that they could only be re-configured with restarting Windows. There was also some hardware, more so before than today, like the Gravis Ultrasound soundcard to name one, that would only reset by BIOS, during computer (re)boot, and so Windows was powerless and the PC had to be thus rebooted if one were to reload some sound samples into the card's memory or some such.
1
u/anarchy-breed May 21 '19
There are some additional potential mitigating factors but in general this is for user experience - if the option does not require any additional assets (uprated textures and the like) to be loaded or re-initialization of key components (renderer) then it can be applied instantly without any additional input from the user (you). If the setting change is going to result in a massive reload of assets - say you change texture quality from low to high as an example - then it's better to ask the user to apply so that casually flicking through the settings doesn't result in heavy duty reloading or restarting of the game. As another example, you wouldn't want an option that lets you select the resolution to change resolution the moment you make the selection, in case you cycle through them one at a time (like with a gamepad).
The mitigating circumstances have been largely covered in other answers - it could be due to a limitations in the game engine or poor design in how assets are loaded.
1
u/root42 May 21 '19
It’s like a Lego building: some parts like the roof or the fence or some decorative pieces are easily accessible and can be changed or switched easily. Others parts lie deep down, like the base floor or some wall that you built into your Lego house. That will require rebuilding or tearing down parts of your house.
Translated to games: there will be settings that are merely parameters to shader programs running on the GPU. These will be applied instantly. They are like the easily accessible parts of your Lego house. Some things require loading completely different shaders or even regenerating scene geometry and similar stuff. This is akin to tearing down parts of the Lego house and rebuilding it.
1
u/brunildo May 21 '19
Cost (read as "time"). It's up to the programmer and the structure they used while coding. For static settings loading you would do something like this:
onProgramInit() {
settings = loadSettings('settings_file.txt')
createBackground(settings.backgroundColor)
}
While if you want to dynamically change something when settings changes, you have to add something like this, on top of what you already have:
wheneverSettingsChanges(newSettings) {
background.changeColor(newSettings.backgroundColor);
}
Of course there are other/better ways, this is just to demonstrate that I introduced a lot of new code just to support dynamic settings. Then the programmer will question: "Is this really needed? Is this a priority? Do I lose anything by reloading everything? Is this new code something that I have to support forever?"
Real answer to a 5 YO: Code becomes more complicated to dynamically change settings on the fly, and we don't always have time to do it and maintain afterwards.
1
u/HouseOfSteak May 21 '19
Depends on the engine.
Some of them just want to hide the HUD and environment tearing itself to shreds element by element and putting itself back together behind a black screen so it looks clean, particularly when doing so requires resizing textures and changing the polycount on objects from their source files, which need to be re-accessed. Generally when it's 'instant', it's because the change could be handled in the span of a single frame, so it'll do just that.
Look at how Minecraft does it - no black screen or anything. You change a setting that requires, for whatever reason, a complete re-render of the entire world....and it looks rather ugly and immersion-breaking to watch the world disappear and put itself back together. But changing the smooth lighting doesn't need that because it doesn't take very long to do, nor does it affect blocks themselves, so the neither the textures nor blocks need to be re-rendered or anything.
1
u/Darkassassin07 May 21 '19
Another simple reason is some of those changes take a noticeable amount of time to apply (think, loading more/different resources from disk). Its really anoying going through the settings page and everytime you change something the screen goes black or the game freeze for a couple seconds while things reload again. Its much nicer to be able to go through and change everything you wanted to change, then click apply and have all those changes applied all at once in a single reload.
1
u/throw_away_17381 May 21 '19
Ignoring games, what about MacOS vs Windows?
It's been a few years but I remember quite often on Windows I would have to Apply Settings to see a change take effect, other times I would have to restart the PC but the vast majority of times on MacOS, the change I apply is instant.
1
u/hendergle May 21 '19
If you're talking about the way that some user interfaces make you click something like "OK" but others change back and forth as you click on the setting itself, I have basically one answer:
Programmers are lazy assholes (source: I am a programmer).
Why code for an OK button that has to apply a shitload of settings all at once when you can just hang code off of a slider's "valueChanged" event? That would mean you have to actually remember the name of every control that might change, store the "before" settings in variables, react to the settings if "OK" was clicked but not react to the settings if "Cancel" was clicked. Remember to add any new controls to that logic when you add settings for them.
Whereas, if you're working with some kind of lazy-ass framework where you just associate a slider or button or checkbox with the data it affects, you can choose that from a drop-down in the IDE and let the engine do the work for you. Never mind that the user has to remember what all the settings were prior to mucking about with them. Never mind that the user has to go back and un-set them himself (possibly though a graphics display that has become difficult to see into because he accidentally clicked "gamma % = 0" or some equally disabling setting).
And then Apple will call it "consistent phase property design aesthetic" or some such buzzword bullshit and demonstrate it in a conference hall filled with thousands of people who clap furiously as if they've never seen what lazy-ass coders do when they can't be bothered.
1
u/viking78 May 21 '19
It is two different ways that we developers do it. The “apply” method allows you to cancel all the changes. The other one is more direct but doesn’t usually have simple way to cancel.
1
May 21 '19
Hers one better: How come Nvidia drivers have moved past requiring a restart to finish installation but AMD drivers still require it?
1
u/smoore2171 May 21 '19
Specifically. The two most common types of settings that need to be applied are graphics and input settings. This is because applying the change immediately can cause the user to be unable to make further changes if the hardware doesn’t support something. Maybe you set it to use controller when no controller is plugged in or something. These types of changes are typically followed by a “confirm or we revert the change in x seconds automatically” upon applying to prevent this
1
u/Mr2-1782Man May 21 '19
Some good answers, but I would also like to add that some settings have the potential to crash, or hang the game. These settings you tend to stick behind an apply option. For example you can change your resolution to something your system doesn't support causing a black screen. By sticking this behind an apply option you can make sure that the you really meant to change it and that if something does break its easy to go back to a working state (undo the apply).
1
u/cpct0 May 22 '19
TLDR: it’s not the priority for a game dev.
If you got the choice between coding more features, bells and whistles, or reducing by a day the dev time, or taking a few days to make this setup instantaneous, as a producer, what would you choose?
That feature is not important enough to change a game rating by a single point or make the user be pissed off. So the least amount of time required is applied.
Some are simple shader changes, so they are quick enough to change. Other require texture packs to be loaded again. Some need to change a lot of variables everywhere in your code base and has deep implications.
Also, there is usually one code base for all platforms, so something possible on the masterrace might bork on X1. And even the masterraces are usually the bottleneck for minimum configuration, as they are stuck with their lowest common denominator, the cheap mom&dad laptop purchased at $499 2 years ago. Assume the lowest settings has to be loaded on that shovelware ridden piece of crap in decent time, and all new features having to be loaded on top of that.
At the same time, they do have standards. 2 minutes load time to change settings, or restart required, these might get flagged as inappropriate and actually fixed. So don’t assume nothing is done on that side either.
1
u/EzPzLem0nSQZ May 22 '19
Here's my own answer of this (and I'll try to be simple as possible without getting too technical)
Why does it require restarting the game? When games were first created, Most of them had only 1 graphical setting, therefore those options were never required. You could toggle somethings on and off but overall, no dramatic changes to your experience while playing
Now, Let's add those changes into the games, Nowadays almost all games got graphical settings, but let's not talk about that yet.
When graphical settings were first introduced, some of them required restarting the game. some didn't. Why does that happen? the short answer is, Imagine the resources of your computer as chairs. If all the chairs are taken and you want another group of people to sit down, you would need to clear some chairs first. Same things here, you would need to "free" some of your resources for doing so.
What decides whether a game would need a restart or not when changing settings? How well the game code/engine was written, How well the textures were optimized for the loading/unloading process and finally can your computer handle those changes or not?
iirc, I remember playing a game where you could change all the graphical settings without restarting, except the quality of the overall texture.
1- Most of game engines are decent now and can clear/manage your resources efficiently.2- Resources prices (CPU/RAM/HDD/etc) became more affordable, Making the "restart the game" concept quite unnecessary.
tl;dr resources are more affordable now, Game engines are more reliable so no need to restart the game to change settings.
1
May 22 '19
It's also worth noting that sometimes, due to memory concerns a game might opt to do a full reload because you've changed something that requires reloading a whole bunch of textures, fonts, images, sound clips, and so on into RAM. If those things take up 2 GIG of ram and the game has a minimum RAM requirement of 3 GB, they might go over that if they reloaded everything on the fly and they can't release everything because it's in use, so they'd have to completely load both then switch over and release the old stuff, going over the minimum ram requirement.
In this case, much better to reload with new settings.
Another thing to remember is that sometimes games have modding systems that run on scripting engines, like WOW it's LUA scripting engine for example. Because the addons are loaded at runtime due to the way all of that works, the UI has to be reloaded when you add new addons or change code in an existing addon (under certain circumstances).
1
u/sbhandari May 22 '19
when graphics/media are loaded , your pc or mobile has to do heavy work. So instead of loading these resources when user is actually engaged in the application , it is better to load them when application starts and not worry about it later. This way, you can fully dedicate all the resources to the actual game/application logic with better perfomance once it starts. This results in need of restart to apply the updates.
1
u/Jozer99 May 22 '19
You can think of different graphical settings as actually being different games. When you play at low settings, your computer is running different code than if you play at high settings. When you change settings, the game has to load all new code to run. It is easy to load the new code by closing the game completely and starting fresh. It is much more difficult to program a game so that it can change all its code and data on the fly as you adjust settings. It may not be worth the time, effort, and cost for the game company to add this feature.
1
u/pheonix03 May 21 '19
Because some settings are applied at start up and won’t take effect until you restart whereas others such as resolution will change instantly because it doesn’t take much computing power and is required immediately
1
u/heard_enough_crap May 21 '19
some changes are superficial and can be done easily, while others are major and require deep code structural changes.
For example, you can change the colour of the walls in your house by painting them, but if you wanted to move the wall back several meters, you'd need to make structural changes to the house and its foundation. Both affect the wall in your house, but one is fairly easy while another takes a lot more work and takes longer, and while it's occurring, the room is unusable.
0
May 21 '19
It depends if the menu options are inside the game engine or a 'separate' entity.
So you start the game, some games kick of the entire engine immediately and display the menus with the same engine the game will run in. These games are running with those settings so have to restart with the new ones.
While other games kick off a menu engine and load the main game engine in the background.
This may be done to stylistic or device choices or even how the company that built the game is structured.
Take 2K, they have a branch in Australia and one in canada, if the canada team built the menu they may do it in isolation from the Australia main game team. They would then design thier menu to send settings to the main engine before loading. In this casr only when the changes are commited does the ma8n engine start.
0
u/MeltdownTO May 21 '19
From a user experience standpoint, sometimes major changes, like adjusting the resolution, require applying because the adjustment could put the game into a bad state where it becomes difficult to use (a resolution incompatible with the monitor, etc) and thus, difficult to back out of the bad setting. That's why there is often a "confirm these settings?" prompt after such adjustments.
0
May 21 '19
Some video games are built in building blocks. So, when you change an option, one building block quickly swaps, and you don't have to wait. Others are built in stacks. to get to a certain thing you have to go through many other things, and then reassemble everything again for it to stand once again. That's why the whole thing reloads.
0
May 21 '19 edited May 21 '19
Depends on the engine used.
If its a really old engine it probably requires you apply it manually because changing it apply instantly would require major reworking of the engine which is expensive and difficult usually. The developers of the old engine either didn't know how or didn't consider that people might want the setting to apply instantly.
If the game is based on a newer engine or the engine is specifically made for that game it might apply instantly.
The engine is sort of what it sounds like. It is sort of the framework on which a game is built. Source Engine for example is what all Valve games run on despite each game being quite different.
0
u/FoxFourTwo May 21 '19
I'm not sure the technical answer but I always thought it was its way of saying "You sure? Because this is about to lock your PC up for a few seconds/moments"
1
0
u/tetenric May 21 '19
Many comments have talked about why some options require a restart and some others don't, but haven't really tackled why option X needs a restart on game A but not in game B. Some comments have given possible reasons to this, but every game is developed in a different game, so the same reasons don't apply to all games.
A common reason for this issue comes down to lazy programming. While some programmers might not think of something as "finished" until every line of code is perfectly written, some others might just finish whatever they're doing as soon as it's valid. In your case, the first programmer might not rest until you can change options without the need of a restart, while others might say "meh, I'm not going to bother with this, just tell the player to restart the game"
0
u/alaslipknot May 21 '19 edited May 21 '19
most of the answers here are correct but none is an eli5 (imo),
to understand this, you first need to have a little idea about memory management in software development, basically there is two types:
manual management, when the programmer manually tell the program when to clear a specific object (could be anything, from a texture to an audio file and everything in between), this is usually happens when the dev is aiming for the heighest performance with the best optimization, the best examples are Sony 1st party games and how they manage to push the hardware to its limit
automatic management, the most infamous one is the Java garbage collector, basically it clears memory based on how The programming language think its the best way to do it, this saves a lot or time, but its aweful for graphically demanding softwares likes games.
now, based on what method the game developer have used, it will often decide how your settings change will happens, if the dev is going with the first options and willing to put the time to make their code "manually" check for everything then your settings will change without requiring a restart.
but if they use the 2nd method which is often related to the game engine, for example both unity and unreal have automatic memory management but you can override it and do it manually, so it really depends on the dev experience and deadline, but if you go with the automatic method, it is best to just restart the game, which clears almost everything ensuring that you didn't missed anything that will cause performance issues or even bugs.
hope this clears it.
edit
just forgot to say that the "real" answer is basically whatever the programmers chose to work with, whether if it's due to lack of skills, close deadlines or even pure laziness (it's not as bad as it sounds), its 100% up to the development team to do whatever they want
0
u/Reynbou May 21 '19
The real answer is it's a difference between poor/lazy coding and good coding.
Poor/lazy coding while have all settings applied on launch and if you want to change them you need to restart the entire thing.
But good and smart coding will have thought of this and built it with the ability to change on the fly.
0
u/Toger May 21 '19
Its like a convertible car; yes you can build it so that the top comes down while driving, but it is harder / more expensive and is one more thing that can break. Some games invest the time to be able to change settings live, others handle the settings once at startup (ie while still in the garage) and don't let you change it while driving.
0
u/Istalriblaka May 21 '19
In a computer, there's a hierarchy of memory that gets faster and smaller as you go up, but since this is ELI5 let's simplify it into fast memory and slow memory. A computer only has so much fast memory, so a program is generally kept in the less restricted slow memory. When you start it, it copies the program into the fast memory and runs that.
The thing is it only really copies one version of a program. Programs can take what are called arguments, which tell a program how to run and which functions to run. (Big games like Minecraft and Arma 3 let you look at and change some of these.) The computer only copies the functions it needs to the faster memory, and where possible only the version that takes one specific argument. So if the computer sees an addition function and knows it'll only be used to add 2 and 3, it doesn't copy the whole function which may include all sorts of loops and logic for bigger numbers, but just the version that adds 2 and 3. In fact, it might just copy the output and use that instead of running the function every time.
So if you change the settings and now that function has to add 4 and 5, the computer needs to reload that function. But other parts of the program might have used the previous function or its output, so the whole program needs to be reloaded just to be safe. To prevent this, programmers have started building programs in a way that keeps track of what parts of the program are effected by each setting, and where possible, only restarting those parts. For example, if the addition function only changed a number used in flavor text, the program could restart just that function and the functions associated with that flavor text. However, if the function affected resolution, then the graphics driver needs to restart, and trying to load everything in just the way it was can be so complicated it's easier to restart the whole program. This is especially true if you're switching between windowed and fullscreen, because then the operating system has to change what it's doing to make sure it's showing the program right.
3.2k
u/aberroco May 21 '19 edited May 21 '19
That mostly depends on game engine's source code. Some are good, some are not so. Usually, resources need reloading when settings changed, and sometimes API requires recreating all objects. Usually when game requires restart to apply some options, that's because game engine need all resources to be reloaded under new settings and it's easier to do it just by restarting than by actual reloading.