This comes down to how the application was written and specifically, resource management.
When a game is up and running, it got there by loading a bunch of pictures (the textures) and shaders (simply, graphical effects) and 3D models off your hard drive (or SSD) and mashing them together. The current settings you use determine which shaders, models and textures are loaded and how they can be processed before they are actually used to display something. Different settings may use different files.
In any graphics API (Open GL, DirectX, Vulkan, etc.), when you want to load a shader or texture or model, it’s given a unique ID. If you unload a shader to change it to another, it now has a new ID that has to be applied to everything that used it so the graphics API knows what items you need to draw something. There may also be different settings (less or more) that are applied to the new shader and the game has to do a little processing before it can start drawing again.
The game engine may be written really flexibly (Doom Eternal) and is able to unload the current files, reload the files it needs for the new settings, re-apply the new IDs and keep going. Maybe they wanted to save time during development (I’m looking at you, Assassin’s Creed: Odyssey) and it requires a restart.
Why would someone do this? For a larger company like id Software and Ubisoft, it can come down to decisions made solely for the company or what kind of experience they want the players to have. Maybe their workflow mandates that the game designers can see changes in-game immediately because maybe the graphics programmers are always busy. So early on the programmers made it so that the artists can just update a shader file, push some hidden command in-game and reload stuff. Maybe they have some external tools they think are good enough and want to use them to save time on the graphics programmers and don’t want/need to see it in-game for some reason, so the game engine was never given that flexibility.
Source: wrote a small game engine and wrote support to reload the shaders while the game is running. I don’t actually have to “apply” the new shader IDs because each object doesn’t point *directly* to a shader. There’s a layer in between. This was the flexibility I made to support dynamic shader reloads. It requires a full restart to change textures but can also dynamically reload changes to the UI.
It’s just how the creators decided to make the game.
The easy way: write the part of the program that sets up 3D, and then 3D is set up and you never have to touch it again. But if you want to change the 3D settings you have to restart the program.
The hard way: write the program so that it can un-set-up and re-set-up parts of the 3D stuff. But then you have to actually make it do that and make sure it works properly. But you won’t have to restart the program to change settings.
I think on old graphics cards and old operating systems, you basically had to reboot the graphics card to change the resolution. But that’s not a thing any more.
Latest Answers