Even if it can't tell how much load you put on your system because that is a complex interaction of various bottlenecks, it would at least be nice if they labelled which settings are likely to contribute to the CPU, CPU, RAM, VRAM,... bottlenecks.

doesn't account for the trade-off between looks and framerate that a player wants,

Yeah, I thought about talking about that in my comment too. Like, maybe a good route would be to have something like a target minimum FPS slider or something. That -- theoretically, if implemented well -- could provide a way to do reasonable settings on a limitred per-player basis without a lot of time investment by the player and without smacking into the "player expects maximum settings to work" issue.

There are also a few people who want the ability to ram quality way up and do not care at all about frame rate for certain things like screenshots, which complicates matters.

I think that one of the big problems is that if any games out there do a "bad" job of choosing settings, which I have seen many games do, it kills player trust in the "auto callibration" feature. So the developers of Game A are impacted by what the developers of Game B do. And there's no real way that they can solve that problem.

Yeah, there are auto-calibration systems, but that's why I'm emphasizing "reliably". I've had some of them, for whatever reason, not ramp up quality settings on hardware a decade later even though it can run it smoothly, which is irritating. In fairness to the developers, they can't test on future hardware, but I also don't understand why that happens. Maybe there's some degree of hard-coded assumptions that fall down for some reason down the line.

Yeah, I agree that the "this particular setting is performance-intensive" thing is helpful. But one issue that developers hit is that when future hardware enters the picture, it's really hard to know what exactly the impact is going to be, because you have to also kind of predict where hardware development is going to go, and you can get that pretty wrong easily.

Like, one thing that's common to do with performance-critical software like games is to profile cache use, right? Like, you try and figure out where the game is generating cache misses, and then work with chunks of data that keep the working set small enough that you can stay in cache where possible.

I've got one of those X3D Ryzen processors where they jacked on-die cache way, way up, to 128MB. I think I remember reading that AMD decided that on the net, the clock tradeoff entailed by that wasn't worth it, and was intending to cut the cache size on the next generation. So a particular task that blows out the cache above a certain data set size -- when you move that slider up -- might have horrendous performance impact on one processor and little impact on another with a huge cache...and I'm not sure that a developer would have been able to reasonably predict that cache sizes would rise so much and then maybe drop.

I remember -- this is a long time ago now -- when one thing that video card vendors did was to disable antialiased line rendering acceleration on "gaming" cards. Most people using 3D cards to do 3D modeling really wanted antialiased lines, because they spent a lot of time looking at wireframes, and wanted them to look nice. They were using the hardware for real work, were less-price sensitive. Video card vendors decided to try and differentiate the product so that they could use price discrimination. Okay, so imagine that you're a game developer and you say that antialiased lines -- which I think most developers would just assume would become faster and faster -- don't have a large performance impact...and then the hardware vendors start disabling the feature on gaming cards, so suddenly cards are maybe slower rendering than earlier cards. Now your guidance is wrong.

Another example: Right now, there are a lot of people who are a lot less price sensitive than most gamers wanting to use cards for parallel compute to run neural nets for AI. What those people care a lot about is having a lot of on-card memory, because that increases the model size that they can run, which can hugely improve the model's capabilities. I would guess that we may see video card vendors try to repeat the same sort of product differentiation, assuming that they can manage to collude to do so, so that they can charge people who want to run those neural nets more money. They might tamp down on how much VRAM they stick on new GPUs aimed at gaming, so that it's not possible to use cheap hardware to compete with their expensive compute cards. If you're a vendor and thinking that blowing, say, 2x to 3x the VRAM current hardware has N years down the line is reasonable for your game, that...might not be a realistic assumption.

I don't think that antialiasing mechanisms are transparent to developers -- I've never written code that uses hardware antialiasing myself, so I could be wrong -- but let's imagine that it is for the sake of discussion. Early antialiasing ran by using what's today called FSAA. That's simple and for most things -- aside from pinpoint bright spots -- very good quality, but gets expensive quickly. Let's say that there was just some API call in OpenGL that let you get a list of available antialiasing options ("2xFSAA", "4xFSAA", etc). Exposing that to the user and saying "this is expensive" would have been very reasonable for a developer -- FSAA was very expensive if you were bounded on nearly any kind of graphics rendering, since it did quadratically-increasing amounts of what the GPU was already doing. But then subsequent antialiasing mechanisms were a lot cheaper. In 2000, I didn't think of future antialiasing algorithm improvements -- I just thought of antialiasing entailing rendering something at high resolution, then scaling it down, doing FSAA. I'd guess that many developers wouldn't either.

I don't like the idea of it needing to be patched in.

At launch advanced graphics mode settings could be something that is disabled by default but unlockable (via config.ini setting, console command, cheat code, whatever). Really the implementation isn't what's important, just that it is opt-in and the user knows that are leaving the normal settings and entering something that may not work as expected.

Then if they are still supporting the game later the defaults can be changed with a patch but if the devs don't have that opportunity the community can still document this behaviour on sites like www.pcgamingwiki.com.