-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to force texture filtering off #8645
Conversation
What happens with existing configs? Do we translate true/false to 1/0? |
I wasn't sure how to implement (as in program, not design) that. That would be the best way of doing it, but for now it resets to Default. |
I can't really agree with the UI and UX approach in this PR. By placing it in the enhancements tab, changing Force Texture Filtering to off is being elevated to the same level as extremely important options like internal resolution, anisotropic filtering, antialiasing, etc etc. This does not belong on that level. Setting texture filtering to force nearest neighbor (more on that later) is an extremely niche option that does not belong on the same level as things users will want to keep configured and accessible. Now you probably put it here because this is where Force Texture Filtering was. But that was a tiny checkmark button that took up very little real estate on the screen, in the midst of lots of other little buttons. Even though it is location in a prime location, it's mindshare impact is relatively minimal. However, this PR turns it into a dropdown, which takes up WAY more space and promotes is puts it right up in the same level as the critical options like internal resolution. This is really inappropriate for a niche feature. Also I don't really think Force Texture Filtering belonged here in the first place. Outside of a handful of games where it genuinely improves things (New Super Mario Bros Wii, Skyward Sword, to name two), it basically does nothing but cause minor visual bugs. But it was small, in the midst of a number of other misc options, and had been there forever, so I never bothered to complain. Anyway, I believe this should be moved to advanced, if we decide to include it at all. As for the naming of the options, that gets a little messy, as texture filtering is more or less a made up term from marketing that's stuck. Ok so, "texture filtering" the term is defined as the remapping algorithm the GPU uses to remap the texture's pixels to the screen's pixels during rendering. Unless a texture is 1:1 pixel tied to screen space (which you can do btw, screenspace huds are a thing!), its pixels HAVE to be remapped by something, and thus, filtered. That includes anything in 3D; scaling and rotation of textured polygons absolutely require texture filtering. Bilinear, Trilinear, etc etc are all algorithms to handle that remapping, but nearest neighbor is also a way to handle that remapping, it's just a more basic way of doing it. It sounds weird, but nearest neighbor is also texture filtering. The only time you get no texture filtering whatsoever is when the texture lives in screen space and is not scaled or manipulated in any way; but that is not nearest neighbor, that's a texture in screen space. The confusion comes from marketing of very very early 3D technologies, where "texture filtering" was used as a marketing name for bilinear. Once trilinear came out they just called it the real name, trilinear filtering, but for a while marketing tried to posit that bilinear is "texture filtering", and nearest neighbor was not. But that's basically never the case, and we're kind of stuck with this not great name for it and that confusion to this day. So, to that end, I believed the naming scheme used here is not correct. You currently have it set to:
What that actually is, laid out accurately is:
How you describe those options doesn't anywhere near indicate what is going on. I'd much prefer something like this:
With descriptors below in the Description area: Default: Allows the game to set whatever texture filtering method it wants for each texture. Anisotropy will replace Trilinear if configured. And of course, this would be in the Advanced tab, ideally. So about that trilinear there. So the GameCube has Trilinear filtering from what I understand. However I'm not sure whether Bilinear or Trilinear is more common. I want to confirm with @stenzek about all of that and make sure the word(s) used there is correct. |
I would drop that "for all textures", though. It would just make the drop-down list even larger especially when you account for translations and I think the suggested description text would already explain better what is going on. I think "Default", "Force Trilinear" (or whatever it should be) and "Force Nearest Neighbor" should be enough... |
That would be fine with me, honestly. The description can carry a bit more of the load in describing how they work, and it's not incorrect, just... simplified I guess. As for Bilinear vs Trilinear, it's both. According to stenzek, apparently mipmapped things are trilinear, and everything else is bilinear (except for textures explicitly set as nearest neighbor). However, most things are mipmapped so, trilinear is more common, from my understanding at least. |
@dolphin-emu-bot rebuild |
So, disabling texture filtering does make a lot of games look nicer at higher resolutions, particularly games that have precision issues with text. I do think the best solution would have a heuristic to try to detect HUD/UI stuff, and allow users to force it, use the heuristic, or disable it. |
@JMC47 Do you have any ideas for how such a heuristic would work? |
I've tried a few different ideas (contrast, attempt to detect a background color, etc.) and my best attempt was based on whether the texture has any transparent pixels, which... shouldn't be great, but using the UI and environment folders from Bighead's Mario Galaxy texture pack (it was the only png textures I had on my computer) it correctly classifies all but a few environment textures and ~90% of UI textures. |
As it turns out, eyeballing it didn't work that great, so I calculated it properly. It's correct for 89.4% of environment textures and 98.9% of UI textures when treating "transparent" as "any transparency," and 91.0% of environment textures and 90.2% of UI textures when treating "transparent" as "full transparency." |
I'm not really convinced that a heuristic that works for even 75% of games is possible, especially without machine learning or something similar. |
Yeah, I don't know if a Heuristic would work, but the fact that this removes visual garbage around text (See: Starfox Assault) at higher resolutions makes it kind of interesting to experiment with. Other ideas for heuristic, even if it isn't promising: Texture Resolution. Maybe projection? |
So this overall algorithm seems to work very well but needs some tuning:
a, b, c, and d need tuning, but currently I'm using 15, 16, 1, and 50. The current values of a and b successfully filter out bell curves (the vast majority of environment textures in my experience), but an approximately equal percentage of environment and UI textures have a single edge, making choosing c difficult. d exists solely because of displacement maps. |
I recall playing a game years ago that had a "trilinear nearest" option for texture filtering, so it used bilinear/trilinear when the texture was scaled down, but when you got close enough to it for it to be scaled larger than its largest mipmap it would be nearest-neighbor scaled. Maybe something like that would work? |
Nice feature, hope it gets merged. |
It would need to be rebased, fixed for Lint, and reviewed in order to be considered. I'm honestly pretty happy with it though as a feature. |
Remembered this PR and I'm happy to rebase it. I'm still not entirely sure about heuristics, though, especially since I'm not really sure what infrastructure Dolphin has for image processing. |
92bc05b
to
11e6a92
Compare
Ooh I was about to try to rebase this myself (but lack the git skills to do so). Really hope this gets merged; in particular, Animal Crossing looks significantly better with this. |
if (!strcasecmp("true", str.c_str())) | ||
{ | ||
*output = static_cast<T>(1); | ||
return true; | ||
} | ||
else if (!strcasecmp("false", str.c_str())) | ||
{ | ||
*output = static_cast<T>(0); | ||
return true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ymmv but I feel this is pretty ugly to have in the middle of what is supposed to be a generic integer parsing function. At the very least I'd pass a flag that defaults to false whether true/false should convert to valid integers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do that, but I felt like the changes necessary were a bit invasive.
any update on this feature? would love to see this in main! The fork works fantastic albeit confusing wording. |
I just want to add my raised hand to the "please merge this feature" crowd. I even tried to compile the fork myself but troubleshooting git and visual studio to get it to actually build proved beyond my capabilities. I want pixelated Animal Crossing textures! I played the fan-translation of the N64 version a little bit, with a graphics plugin (Glide64mk2) that has a nearest neighbor filter option (although they call it "force point sampled", which might be more correct IDK), and I can confirm that it (subjectively) looks much better that way. If the translated rom hack hadn't kept crashing on me I might've stuck with it despite the lack of added features from the Gamecube version. |
11e6a92
to
8eb96dc
Compare
(probably should've built the rebased version before pushing, oops. still going to address the other issues) |
Make sure you combine fixup commits into other commits, so that the only commits that exist are the main changes that you want split up for easier review. I do think this would be a good change, as there are games that are broken even on console due to using the wrong filtering mode. See: Blaster Master WiiWare, and Sexy Poker for easy examples. |
8eb96dc
to
a6a66ae
Compare
… converting checkboxes to dropdowns
a6a66ae
to
3c3e613
Compare
I'm still against the Otherwise this looks fine to me. The setting description might need to be reworded. |
I agree with you. However, I'm going to go a step further, I think I'd prefer breaking config entirely:
to
I do think it'd be nice for Dolphin to have a proper workflow to upgrade config when changes require it (or give some notification if a breaking change occurs). However, I don't think trying to fit backwards compatibility into every change we do is the right way to handle it. |
I'm still not happy about this being in the enhanced tab. It really should be in hacks or advanced imo. |
IMO enhancements is the proper tab for it (for the same reason why forcing texture filtering is there and forcing anisotropic filtering is there (compare #9975)). Most of the arguments I can think of for this belonging in the hacks tab would also apply to the other enhancements; particularly disable fog, disable copy filter, per-pixel lighting, force 24-bit color, and widescreen hack. |
Well it's kind of a mixture. Force texture filtering is an enhancement (extrapolating from how the console works), while disabling texture filtering is hack (that's not how the console works at all). The reason I think the whole selection should be in hacks is because of the enlarged real estate that the dropdown has puts more emphasis on it. |
Forcing texture filtering is probably more likely to break things (at least, it is known to break FMVs using Bink Video (on the Wii), and I think also EA VP6), which depend on getting a specific pixel's value without interpolation. I'm not sure if force-disabling it breaks anything (it probably makes some indirect texture effects look worse such as the wind waker map and the color filtering in EA Sports Active, but I don't think they'd completely break). I feel like the hacks tab is more for things that increase performance at the cost of accuracy, while the enhancements tab is for things that adjust rendering to one's preference at the cost of accuracy (regardless of the hackyness of the implementation). Both tabs currently have about the same amount of stuff vertically, and putting it in the hacks tab would either require putting it in a new section (increasing the height of hacks even more) or putting it in the "other" section (which seems suboptimal). |
Regardless of personal preference, most users will use this like an enhancement. |
Just want to note that forcing nearest neighbor does introduce some issues in certain scenarios. For example, Animal Crossing City Folk's grass does not render correctly. I do still think this is better as an enhancement regardless. |
I don't understand why one of the two should be considered a 'hack' and the other not. As I understand it this is just a flag on a texture that the game can set to 'yes' or 'no' in each rendering instance, and all this option does is force that flag to be either of the two instead of what the game intended to set. How is one way different than the other? |
Just my two cents as a user, is that
is how I feel. I would be looking in the "Enhancements" tab for something may improve the looks of a game depending on my personal preferences. Especially since it has to do with texture and scaling, it fits really well with Internal Resolution, AA, AF, etc.
Really interesting post about marketing naming btw. |
What's the status on the possibility of this being merged? I would be willing to step up and make changes that would be necessary to do so. This feature is very useful for Animal Crossing in particular, and I'd love to have it end up in Dolphin properly. |
Well first of all, this PR would have to be rebased and its conflicts resolved. If we are attempting to target specific elements, just personally I think this would be better as a Graphics Mod but that hasn't been merged yet either. |
-> #11276 |
I saw this requested on Reddit. I thought it would look horrible, but I think I might actually prefer it to bilinear filtering.
Menu (ignore the titlebar, that's a bug with my screenshot tool):
Default:
Force:
None: