EDIT: Read my latest post first.

There's a big question I want you to answer that's fundamental to all this.

What does Force Nearest make better in Dolphin?

For the PS1 or something, where you have lots of 2D sprites in screenspace and some really dumb filtering choices on the console itself, texture filtering controls are essential. Many other emulators have the same reasoning - lots of 2D content with dumb filtering choices. GameCube and Wii games on the other hand are almost entirely 3D. There is extremely little content that would be improved by Forcing Nearest Neighbor.

Our main source of 2D content is the Virtual Console. In which case we're emulating an emulator which has its own controls for things like this. Not to mention Dolphin isn't the best for emulating those titles anyway, as a dedicated emulator made for that console will always be superior to Dolphin's Virtual Console experience. The main justification that I can think of is WiiWare. They are 2D typically and not available on other platforms, they may benefit from this feature. However, they were designed with the texture filtering everything world in mind so there aren't a lot of blocky pixel games - usually they are drawn sprites. Pixel art games that exist (Mega Man 9 for example) just use nearest by themselves and us forcing it gives them nothing.

I've been against it because it's elevating a feature that doesn't provide anyone any benefit to a prominent place in our GUI. Sure people have asked for it, but just because it provides a benefit to emulators for other systems doesn't mean it provides a benefit to Dolphin. If this is just for aesthetics because people like how it looks, then it should just be in Post Processing or something as a visual effect, and not be in the midst of critical enhancements like internal resolution.

So sell me on this. What games are better with Force Nearest?

Regarding the Radio Button vs Dropdown style, I think we should go with the dropdown list of the original PR.

When accounting for translations, I can picture the entire graphics window getting super wide depending of the language, as there's barely any space left with the original English strings. The dropdown list would provide more horizontal space without making the window larger since it would display only a single option per line instead of three, like in the current Radio Button design.

Now, regarding the actual placement in the GUI, I don't think it should be moved elsewhere, as it's simply adding another mode to an existing setting that has been in the Enhancements tab for ages now. However, if getting this PR approved means the GUI option absolutely needs to go to another place, so be it. Like Admiral already said, I'd rather have this option somewhere than not at all.

Speaking of the GUI, I would like to point out that opening any PR that touches Dolphin's GUI has become a sore spot lately, with perfectly fine changes (code-wise) and new features often getting held on an endless "waiting for merge" limbo just because they dared to touch the GUI. To be clear, I don't think our current GUI (overall) is perfect, far from it, but there seems to be an implicit high standard to achieve and a need to get things nailed down perfectly at the first try that is unnecessarily stalling Dolphin's progress, and this has been going on for a long while now.

I'm aware MayImilae has plans to rework our Graphics Settings GUI, but this PR is another example of a new feature getting held back indefinitely due to not meeting the requirements of an improved GUI (with hopefully updated guidelines) that currently does not exist and that may or may not come out at an unknow time in the future. The improved FPS counter (PR #10988, now superseded by #11212) is another example of this situation, and that's just counting PRs that touches the Graphics window...

EDIT: Read my latest post first.

All of my GUI complaints in #11212 were quickly resolved. It was good to go, but before I could push for a merge the author changed their scope and expanded it yet again. This is like the 3rd time that has happened. The Eular change is really great so I really want to see that in Dolphin, but I can't help them achieve their goal if they keep moving the goal post. So I don't know what to do there. Last I left it they were trying to decide how they wanted to proceed, and they went silent due to school and other reasons. So we'll see. When they return I hope I can help them further. They are doing cool work but seem intimidated by OSS.

Anyway, everything I've said here is within the scope of the current GUI. In the QT era we have always weighed the benefits of options with their placement. That's why our GUI is as good as it is currently.

So regarding this PR, I'm convinced that you won't be able to find many if any good examples of this feature improving games and that it doesn't justify this placement. So, prove me wrong! Give me examples of Nearest Neighbor making games better. Show me why it belongs with our most important enhancements.

So I've been pondering this all night, and I think I may have found a way to both eat and have our cake. Anisotropic Filtering, our "Force Texture Filtering" override, Nearest Neighbor filtering, etc etc are all Texture Filtering related options. Let's lean into that!

Let's change the "Anisotropic Filtering" dropdown to "Texture Filtering". Then in the drop down, we'll have Default (why 1x aniso? that was on my list), then Anisotropic 2x, 4x, 8x, and 16x, then Force Linear, Force Anisotropic 16x, and Force Nearest Neighbor.

And that's it, there's no need for anything else. No additional dropdowns, no radio buttons, nothing. And the Force Texture Filtering option gets tucked away which is something I was wanting to do anyway. This will require some work to explain in the tooltip, but fortunately we have good tooltips explicitly for this reason. I can help you write it if you want.

This is something I'm totally happy with. By combining it with our other Texture Filtering options, it is now sharing importance with Anisotropic Filtering, and there is no longer a UX weighting problem. It's tucked away a little but it's still easy to find for anyone who knows what they are looking for. And they are all texture filtering options, so this all makes sense. I'll ask someone more familiar with graphics than I am to double check that I'm correct with how force texture filtering combines with Aniso but I believe the "Force Anisotropic Filtering x16" and "Force Linear" dual options should cover that. Of course that means technically that users can no longer combine Aniso x2, 4x, etc with Force Texture Filtering, but honestly there isn't much of a reason to to use anything below x16 on any PC that isn't 15+ years old.

What do you think of that proposal?

I think that's a fairly reasonable place for it. However, I do wonder how it would interact with #9975 - games can enable anisotropic filtering, and currently we ignore that. Ideally, we'd have an option for using the game's value (or just always use it), and I'm not sure how best to indicate that. (That PR currently doesn't change the UI at all, and uses the game value or user value, whichever is higher.)

It would also cause problems for #11093 which disables the anisotropic filtering dropdown when manual texture sampling is enabled.

It's possible to use anisotropic filtering without linear filtering (see OpenGL's EXT_texture_filter_anisotropic.txt), but "Implementations are also permitted to ignore the minification or magnification filter and implement the highest quality of anisotropic filtering possible." I did test on real hardware at one point, and determined that anisotropic filtering does at least still push back mipmaps with linear filtering disabled, and it might also do some kind of filtering but that was harder to tell.

Well, I was hoping for a few more opinions, but alright...

First off: Fundamentally, I think the look of nearest neighbor scaling or linear scaling is one of personal preference, and I don't think we should be the arbiters of personal preference, especially if we can very easily provide the option. (I also think we should have more options for aspect ratio, because having those is not hard and if the user wants to run games stretched to hell, let them!)

As for combining the Anisotropic and Texture filtering... I've never seen anyone do this before, but I guess it's fine? Though I honestly do not understand why having an extra dropdown here is such a big problem.

Personally, having a "force linear and 16x anisotropic" choice without having corresponding options for the lower numbers just feels like strange design to me. Yes, the other ones probably aren't used very much, but it's the kind of thing that makes me go "what?" when I see it and then I have to think about how the heck the option is designed before I can start thinking about which option I actually want to choose. I don't see what's so bad about having this be two options, especially not when we already have an option for forcing texture filtering.

It's possible to use anisotropic filtering without linear filtering (see OpenGL's EXT_texture_filter_anisotropic.txt), but "Implementations are also permitted to ignore the minification or magnification filter and implement the highest quality of anisotropic filtering possible." I did test on real hardware at one point, and determined that anisotropic filtering does at least still push back mipmaps with linear filtering disabled, and it might also do some kind of filtering but that was harder to tell.

For extended context, see flyinghead/flycast#574 where I added this force linear/nearest option to Flycast. This caused regressions such as flyinghead/flycast#695, until anisotropic filtering was forcibly disabled when nearest-neighbor filtering was forced. In my experience, NVIDIA handles nearest-neighbor + anisotropic filtering, but other vendors don't seem to do that as well.

Regarding as to why you may want to force nearest-neighbor filtering on a game, it usually boils down to two reasons:

• Avoiding HUD artifacts with elements composed of multiple textures when using resolution scales above 1×. Some emulators tackle this by adding a way to disable filtering only on HUD elements. The downside is that this introduces uneven pixel scaling, unless you enforce integer scaling on the final viewport size.
• Preferring sharp textures, even if that means introducing aliasing between pixels (unless SSAA is enabled). While this makes sense to do in something like a PS1 emulator, it's clearly not how most 6th-generation console games are meant to be rendered (especially 3D ones). I sometimes like the look of nearest-neighbor filtering in games that used linear filtering on original hardware, but I generally prefer using HD textures if available instead.

If you really want to, you can emulate how nearest-neighbor filtering looks while keeping linear filtering via a fragment shader. This likely avoids edge cases related to anisotropic filtering + nearest-neighbor filtering. It's even possible to smooth out pixel edges this way 🙂

Lastly, there's always the bruteforce approach of upscaling images with nearest-neighbor filtering (4× scale or more), then rendering those textures with linear filtering. It's wasteful in terms of VRAM usage, but it doesn't require custom shaders.

but honestly there isn't much of a reason to to use anything below x16 on any PC that isn't 15+ years old.

Make sure to test this on integrated graphics and mobile GPUs as well, as this may not be the case there due to limited memory bandwidth. In most situations, 8× is probably the highest reasonable value there.

Honestly that long dropdown of options makes it a bit too hidden for my liking.

What about one additional click is too hidden? Even with that additional click, it is three clicks from the game list. That's the same accessibility as changing Internal Resolution, it's extremely accessible.

I still don't get why those two options must be combined on the same drop-down list. One is dealing with the filtering type, the other with the filtering quality.

The current all-in-one dropdown from the most recent proposal is already long and will become even longer after adding the remaining Linear + Anisotropic combinations (IMO providing only Linear +16x anisotropic when the other linear + anisotropic combinations are also valid is just bad design).

Why can't we have one dropdown for choosing the filtering type (default, anisotropic, force nearest, force linear, force linear + anisotropic) and another for controlling its quality (e.g. change its state to disabled unless anisotropic or force linear + anisotropic is selected on the filtering type dropdown). The quality setting doesn't even have to be a dropdown, a slider could work too.

This is all about weights in the GUI. It's a design philosophy for optimizing an existing GUI, with a focus on placing important things first, less important things second, and you go through the whole UI and weigh it all out. While weighing alone doesn't make a good UI, extremely contrasting weights are a sign of a serious problem.

99% of the time users will be using default or x16 anisotropic filtering. All the other options, like Anisotropic Filtering 2x, 4x, etc, are all legacy and don't matter today. If weighted by importance exclusively, those other Aniso options should be INI only, with Anisotropic Filtering as a checkbox. Nearest Neighbor Filtering is an optional graphics mod and, if weighed entirely on its own, belongs with other visual effects like post processing. But perfect weighting doesn't make a great UI alone, it's just a tool to finding problems. There are many reasons for not scattering related options throughout the UI, so a balance must be struck. Bundling them together means that all texture filtering is now the weight, allowing it to hold its place beside Internal Resolution and the like. Plus nearest neighbor gets to remain obviously in Enhancements without any issue. It's a good compromise solution. No one is happy, no one is upset, everyone feels like it's meh - as is how compromises work. :P

Genuinely, if you are bothered by how long the list is, I'm all for removing 2x, 4x, and 8x Anisotropic filtering options entirely from the GUI. We don't need them, but they are so ingrained that I didn't expect anyone would go for that.

BTW a typical modern game's solution to the Aniso options not longer matter is to remove Anisotropic Filtering from the GUI entirely, but we can't do that as an emulator. Would be nice though.

Is having an extra option in the Enhancements tab really so much worse than having a long convoluted dropdown? Feels strange to me. I mean, I understand your reasoning, but to me the strangeness of this dropdown outweighs the benefits of having the Enhancements tab be one line shorter.

It's a good compromise solution. No one is happy, no one is upset, everyone feels like it's meh - as is how compromises work. :P

IMHO the current proposal is worse than any of the previous attempts, so no, it's not a "meh" feeling for me (far from it) and definitely not a good compromise. Is having one less line at the Enhancements tab really such a big deal to deliberately go with a completely avoidable compromise?

Also, why removing existing settings (taking out all anisotropic levels other than 16x) even being considered here? It would make the convoluted dropdown smaller while doing nothing to address why the filtering mode and the filtering quality absolutely must be in a single dropdown list. On the contrary, it would just completely extinguish any control over the anisotropic filtering quality, turning it into an "all or nothing" setting.

Anyway, I still stand behind what I said when this PR was opened (rather have the option somewhere than not have it at all), however MayImilae so far is the only one going against having an extra dropdown (or something else) in the Enhancements tab for controlling the filtering quality separately and although I respect her background with UX/UI design, I do not agree with the reasoning to go that route (in this particular case) and the counterpoints provided so far have failed to convince me the single dropdown solution is either acceptable nor a good compromise...

Also, why removing existing settings (taking out all anisotropic levels other than 16x) even being considered here?

Because it doesn't matter, and removing that baggage is a way to shorten the list.

Just, think about it. Why do the additional anisotropic settings exist? x2, x4, and x8 Anisotropy levels were necessary due to bandwidth limitations of parts long ago. But in the PC space at least it hasn't mattered for 20 years. Even in 2002 PC gamers were just setting Aniso to x16 and forgetting about it. And since in GPU bound scenarios (remember we're usually CPU bound) Dolphin is limited by ALU not Textures, the many Anisotropic Filtering modes have never mattered to Dolphin EVER.

The only reason Dolphin ever had the additional Aniso options was because everyone else had them. And the only reason to keep them around was because it's always been that way, and that it didn't hurt anything. But if it ever gets in the way, we can just remove them. Nothing of value will be lost.

However, we don't have to remove them. I already shortened it by not including the unnecessary aniso options for everything, as shown in the image above. It's only 8 entries long. With that we aren't removing them entirely but not letting it get in the way. I planned for this~

But in the PC space at least it hasn't mattered for 20 years.

I would like to remind you that 40-50% of our users are on mobile.

Well, I guess we could do a separate UI design for mobile, but I do like to keep them in sync unless there's a good reason not to. And there are also people running Linux Dolphin on low-end Mali Chromebooks.

In case we do decide we don't care about levels 2x-8x, I think we should remove the "standalone" versions of them for consistency. Having them for one but not the other is the strangest part of this design IMO.

As a user who isn't amazingly tech savvy this dropdown is a bit convoluted. The previous implementation being separated into two dropdowns made it less overwhelming, and more understandable with the titling (anisotropic filtering vs texture filtering). Weighting options in terms of importance to bring attention to them matters, but when that weighting results in multiple different options being bundled together, it risks the end user getting confused as to why they are all together, what distinguishes them from each other (filtering type vs filtering quality, especially with force linear and 16x combining both Vs standalone versions), and how they work.

Then we could just strip out filtering quality entirely, so the only Anisotropic Filtering quality option presented is x16. Radical as that may be, x16 is all that matters for Dolphin anyway.

That's not radical, that's dumb.

Dolphin nowadays has a huge user base and can run on a wide variety of hardware (including a lot of potato PCs and other niche hardware we don't even know about). How can you ensure that all of them are able to use Anisotropic x16 without a performance impact? Maybe those users can run x4 or x8 fine, but not x16.

If this goes through, are they expected to just deal with it and get themselves locked out of an enhancement they used to have just because it became an all or nothing setting? The same can be said about the Linear + Anisotropic option this PR adds, we're potentially locking users out by just providing "Force Linear + Anisotropic 16x" when there's no technical reason to not provide the other anisotropic levels. That's especially bad since it's just an UI change, it's not like this is a fundamental change to our video rendering code that makes the other anisotropic levels unavailable.

I'll repeat again, dropping existing options to make a bad (and avoidable) compromise feel less bad isn't the way to go. I'm genuinely perplexed you're wiling to go that far just to have one less element at the UI...

Dolphin nowadays has a huge user base and can run on a wide variety of hardware (including a lot of potato PCs and other niche hardware we don't even know about). How can you ensure that all of them are able to use Anisotropic x16 without a performance impact? Maybe those users can run x4 or x8 fine, but not x16.

I'm going to have to call citation needed on that. I've provided a technical reason why those users do not exist, and that came from a graphics dev, not me. So, prove it. Show hardware and/or users that can't run Anisotropic x16 at fullspeed but can at x8 or x4 or whatever.

To throw my hat in here too, I fully agree with mbc07. I genuinely do not understand your hang-up here. I'll also note that, despite it being a non-issue on modern PCs, it is still completely standard to provide the full swathe of anisotropic filtering options in PC game settings, so not providing them would seem much more strange to users than doing so.

it is still completely standard to provide the full swathe of anisotropic filtering options in PC game settings, so not providing them would seem much more strange to users than doing so.

You are incorrect - it's only the standard to provide all the quality settings if you show Anisotropic Filtering in the GUI. The standard in recent games is to turn on x8 or x16 Anisotropic Filtering by default without providing any GUI controls whatsoever. Cause it doesn't matter and hasn't for years. We can't go that far.

To throw my hat in here too, I fully agree with mbc07.

Though the aniso quality settings are needless, I already knew that removing them was controversial and unlikely to happen. Even if a user doesn't benefit from having a choice for something, no one likes it when that choice is taken away from them. I get it. So, if you really want to maintain the Aniso quality selection I think the current setup of limited Aniso options, ala what is in the screenshot above, is still a good choice.

I'm going to have to call citation needed on that. I've provided a technical reason why those users do not exist, and that came from a graphics dev, not me. So, prove it. Show hardware and/or users that can't run Anisotropic x16 at fullspeed but can at x8 or x4 or whatever.

You just mentioned "PC gamers" on your technical reason comment and that implies high end hardware. You also keep mentioning that modern games just enable anisotropic filtering without providing any GUI control and while that is true, Dolphin is not a PC game.

It can run reasonably well on older systems that holds no chance of running native PC games, where bandwidth limitations can be an issue with integrated graphics (especially older ones paired with single channel RAM), and I'm not even accounting for other systems (like low-end Chromebooks, already mentioned by JosJuice).

Though the aniso quality settings are needless, I already knew that removing them was controversial and unlikely to happen. Even if a user doesn't benefit from having a choice for something, no one likes it when that choice is taken away from them. I get it.

You're assuming all of our userbase has hardware recent enough to not have performance issues with Anisotropic x16. I'll ask again, how can you ensure that all of them are able to use Anisotropic x16 without a performance impact?

So, if you really want to maintain the Aniso quality selection I think the current setup of limited Aniso options, ala what is in the screenshot above, is still a good choice.

No, it's not. If we're going to compromise and accept that convoluted dropdown menu, then it should have the missing Force Linear + Anisotropic x2/x4/x8 combinations too.

Edit: I missed the recent code push to this PR. It now has the missing Force Linear + Anisotropic x2/x4/x8 combinations in the dropdown. Although I still prefer having that list split in two separate controls, the current design LGTM.

EDIT: Do you want to move this to IRC so we can chat more quickly? I'm there if you want to.

You just mentioned "PC gamers" on your technical reason comment and that implies high end hardware.

I also said "It didn't matter in 2002". It wasn't limited to high end PCs then, and it certainly isn't now. I played PC games in 2002, on budget to midrange hardware. Even then, I'd just crank the Anisotropic Filtering setting to max without even thinking about it. We've come a loooong way since then.

You're assuming all of our userbase has hardware recent enough to not have performance issues with Anisotropic x16.

Because Dolphin is usually CPU bound, and in the rare GPU bound scenarios we are bound by ALU, not textures. Anisotropic Filtering at lower than x16 is only necessary if you are texture bound. We never are.

You keep saying that people will be affected without providing any evidence. My evidence is Dolphin, and the words of a developer who built much of Dolphin. Prove me wrong.

No, it's not. If we're going to compromise and accept that convoluted dropdown menu, then it should have the missing Force Linear + Anisotropic x2/x4/x8 combinations too.

sigh It's only convoluted if you force tons of additional options for no reason. Honestly, what is your real reason for wanting ALL these options? I know you won't be affected, and you haven't provided any evidence that anyone would be affected. Why does this matter to you? Why does it bother you?

I also didn't notice that the additional options were added. Well fine, having it in the single dropdown is sufficient. I'll make a dedicated PR with something nicer on my own later, where it will be my problem directly. This will do for now.

Legacy beats design once again. Shoganai.

For reference, here's a screenshot of the current design (not a fan, but all things considered, this LGTM):

You keep saying that people will be affected without providing any evidence. My evidence is Dolphin, and the words of a developer who built much of Dolphin. Prove me wrong.

I know for a fact you can go as old as a 4th gen Intel nowadays with Dolphin and still run most of the GC/Wii library at fullspeed with the Haswell-era iGPUs (excluding obvious outliers like MMU-enabled games and other known demanding titles). The point is, if I disable the NVIDIA GPU from my old desktop (that has an overclocked Pentium G3258) and go just with the iGPU from it, cranking anisotropic filtering too high will cause frame drops in most games I own.

I can't test all old hardware available there, but I have this evidence that my old desktop can still run current Dolphin versions with its iGPU just fine, with anisotropic filtering enabled, as long as I don't crank it all the way up. Considering the wide variety of hardware combinations that can run Dolphin, this desktop very likely isn't the only old system out there in the same situation.

So, lower anisotropic filtering levels are still valid enhancement options for people with those old systems (as is the new "Force Linear + Anisotropic" choices provided by this PR) and thus I'll never agree in dropping (nor hiding) those kind of options from Dolphin when the only reason driving such change is "it must be removed from the UI because of design reasons". Design should never limit user choice (especially if it can improve their experience), especially when the underlying code providing that choice remains intact in Dolphin's core and is very, very unlikely to go away any time soon (if ever).

sigh It's only convoluted if you force tons of additional options for no reason. Honestly, what is your real reason for wanting ALL these options?

For me it's not related to how long the list is, it became convoluted the moment you pushed for having texture filtering type and anisotropic filtering quality all under the same umbrella. Those are different settings controlling different aspects of the texture filtering and IMO they should have remained separate (but we're long over that and, although not a fan, the current design LGTM). Since it ended convoluted anyway, just give users the full range of available choices, the reason why already explained above.

Hear me out: I merge the feature as is to get it put in, then we continue to argue about the UI end of it in follow up PRs.

Note: I think the way it is now is extremely stupid and bad.

Sure.

Okay, since I have LGTM from both sides, we'll argue this out in follow up PRs and issue reports or whatever. Having the option is useful, even if the UI for it is less than perfect.