(05-06-2018, 10:51 PM)Renazor Wrote: 3. Makes good sense and I do agree with other stuff too. So because a lot more things are still hacks when it comes from the original console viewpoint, we don't sort them by that because one tab would be too crowded.
Conditions for Hacks tab (draft):
- Hacks that are not going to make graphics look better go into Hacks tab.
- Hacks that are namely for increasing performance but don't necessairly negatively affect accuracy
- Hacks that are going to affect the accuracy of the emulation in a negative way, but in turn may increase performance
- A bit of a conflict there, I'd have the ones which negatively affect accuracy separated or notified somehow - also are there any existing hacks that do improve performance without causing accuracy loss?
- What about the hacks that actually improve accuracy (if they're not the default already), could they even exist, do they already? Heh that's just an my mind's inversion probably, it's a hack that improves performance but when disabled you get more accuracy.
Do we need to split such things into a separate Tab? Separating by group-box in the current Hacks tab, the ones that affect accuracy positively or don't affect it at all separated from the ones which negatively. Or a simpler approach, just tagging the ones which have a negative effect on accuracy. A tag would look like a "i" icon which would be tiny and not bother anything, a popup would appear only when mouse is hovered, for example.
The whole thing could even be fixed by a bit more radical but simple change, renaming the existing Hacks tab into "Performance Hacks" for example, that also fixes the conflict with it being a place for just hacks, because as we see we would have to put a lot more into Hacks if you would just take the context of the tab name.
Also one conflict is with 1. "A quick solution" is it quickly implemented, how does it affect accuracy, is it experimental option, can it be improved?
Maybe just drop the "quick solution" description because it makes it sound that as if it was developed in dolphin in a crappy way - you can have something developed as good as it can get and still be hacky in the end from the original's viewpoint.
So I wouldn't tag all the hacks with "quick solution", they should be individually tagged as "experimental" if they fall into this category I explained.
Are you thinking what I'm thinking ... wild idea, some kind of a hotkeyable switch that would overlay/add an colored indicator or simply change the color of the option's text for which category of accuracy it
User would open settings, normally see as things are right now.
User would like to see which options affect accuracy, how badly?
User would press a hotkey (and reopen settings windows if necessary)
User would see colored options, green = no loss of accuracy, blue = minimal loss, yellow = some loss, red = considerable loss of emulation accuracy.
Sliders would be a bit harder, the option name wouldn't be colored, but the description and the pins, but also the static position-hook indicator underneath the slider.
Such a thing could also be highly volatile setting, if some of you have reservations on causing annoyance, it would go back to default normal colors immediately once settings window is closed and reopened.
Could be possible with Qt now, if not Wx. This would avoid having to go option by option and edit descriptions/translations for the accuracy effect.
Ofcourse this is only worthwhile if there's even a lot of options with various accuracy effects, if it's just a few then no.
Simply said... ALL settings in Enhancements and Hacks and Advanced affect accuracy. And the loss depends per game...
If a game doesn't use Bounding Box nothing changes, but if that game happens to be Paper Mario it is all of a sudden game breaking.
Same with EFB/XFB, if you do not have one of those enabled (always forget which one) you are unable to pickup star bits with your Wiimote cursor which is not game breaking but other games works completely flawless since they just don't use the function at all or in that way.
Another one is Force Texture filtering and anisotropic filtering, most FMV in game don't care about it, but as soon as it is encoded in VP6 it makes all video's a garbled mess.
Already accuracy gets sacrificed automatically if is just a very very minor thing but gives quite some performance boost, like in SSB where after a match there should be a small victory pose of the winner which is done in EFB/XFB (always forget which one) if that is turned off the victory pose is purple/not visible. If you turn it on you see the victory pose but might halve the performance.
Even Internal Resolution increases have issues in some games: for example the Bloom in a lot of games get overexaggerated (or just plain broken) thanks to the way Bloom works on the consoles, or you might see some lines across the screen that shouldn't be there, which all goes away at 1xIR.
Check my profile for up to date specs.