Dolphin, the GameCube and Wii emulator - Forums

Now that Qt is default, it's time when this finally comes in.

Considering that technically more things are hacks than just the things included currently on the Hack tab.

• I suggest renaming the "Hacks" tab into "Caches" or "Buffers" or some even more appropriate name for EFB/XFB/Tex Cache (but with new unified system under ubershader settings aren't some of these options obsolete?)
• A new "Debug" tab added.
• Custom Textures would be removed from the Utility groupbox in the Advanced tab and moved to either a new groupbox under Advanced tab or under a new tab.
• Custom Textures could be more on it's own rather than just a needle in a haystack, it could possibly have a slider two (or the one with 2 pins if possible in qt?) which would control the maximum and minimum prefetch allowance in % of maximum RAM and or VRAM on the system, with some kind of a minimum limit like it would allow the slider to go below 10% and above 95%, and additional checkbox option would be added whether to use RAM or VRAM or even BOTH for prefetching, there was a plan to add support for VRAM prefetching but not sure what happened to that.
• All the debug stuff on the current "Advanced" tab would be moved to the new "Debug" tab - Utility groupbox and Debugging groupbox -
• The options under "Other" groupbox in the old Hacks tab should be moved to the "Advanced" tab under "Misc" groupbox and that groupbox naming should be decided, whther to keep Misc or change to Other or spell out Miscellaneous in full.
• The "Other" groupbox in the "General" tab could get a better name, because if it's on the general tab it's means it's more important than being some other thing? These options could be presented as General without any groupbox, positioned a bit differently so it would look okay, not an unnamed groupbox.
  

This is one part of an overall idea from way back to summer 2017 where I was briefly mentioning it, botto guy was interested in it but I never got to explaining it in full, and still not now because I'm trying to find the logfile with all the points I wrote down, there was some idea around the graphics resolution options not being optimal which was changed in-between then and now as others have recognized the same issue but I don't know if it fixed it the way I originall imagined, and also some changes sorrounding some of the sizing options with the "auto adjust window size" option, whether it should be moved to another tab or not, I see some talk about this option right now so I will postpone with my idea and figure out what's going on with that first.

EDIT: Nevermind I just recalled it's not in a textfile but a DRAFT post right here on this forum, lovely feature:

Quote:DOLPHIN GUI GRAPHICS WINDOW SUGGESTED CHANGES
DRAFT 1.0 - (To be used for QT GUI in some fashion)

----- Global:
---- Placement of tabs "Hacks" & "Advanced" swapped
---- Add "Debug" to the rightmost place

--- General Tab:
-- GroupBox "Basic" & "Display" and their items merged, dropping "Display" text
- Label "Backend:" renamed to "API:" or "Backend API:" (it doesn't feel full enough, it feels like talk in a chat message)
- Add new dropdown option "Display Mode" with options "Fullscreen", "Windowed, Free" and "Windowed, Native Bound"
- SubOption "Fullscreen" should replicate the behavior of option "Use Fullscreen"
- SubOption "Windowed, Native Bound" should replicate the behavior of option "Auto adjust Window Size" (because that's what that option appears to be doing right now)
- Remove option "Use Fullscreen"
- Remove option "Auto adjust Window Size"

- Function: SubOptions "Windowed, Free" and "Windowed, Native Bound" unticked will grey out the option "Fullscreen Resolution" and
set it's value equal to the value of option "Internal Resolution".


--- Enhancements Tab:
- Option "Internal Resolution" moved to tab "General" into groupbox "Basic", below the option "Fullscreen Resolution"

And not even finished it, but the things I said today should override the old ones, I still feel not keeping the Hacks tab named "Hacks"

If it should be kept then I think first some kind of a standard should be figured out which would determine whether something is a hack and each option should go thorugh some discussion with everyone else which things are considered Hacks that would go there.

Then becomes the issue, what do you want to call "Widescreen Hack" then, would it retain the name, or would it just be moved to the Hacks tab, which makes sense from a naming point of view, but not from a functional one, since it's very close to basic settings around resolution, I don't have a problem with moving it tho.

Also I'll reevaluate the draft later and post more updated ideas where my stand is.

EDIT2: I saw and read the reasoning behind the complete removal of the Fullscreen Resolution option, but at the time didn't recall and connect it with my draft ideas so I'll go back and compare the two again, so yeah some of the things I meant were already fixed looks like it, which is a great start.

(05-02-2018, 10:43 AM)Renazor Wrote: [ -> ]Now that Qt is default, it's time when this finally comes in.

Considering that technically more things are hacks than just the things included currently on the Hack tab.

• I suggest renaming the "Hacks" tab into "Caches" or "Buffers" or some even more appropriate name for EFB/XFB/Tex Cache (but with new unified system under ubershader settings aren't some of these options obsolete?)
• A new "Debug" tab added.
• Custom Textures would be removed from the Utility groupbox in the Advanced tab and moved to either a new groupbox under Advanced tab or under a new tab.
• Custom Textures could be more on it's own rather than just a needle in a haystack, it could possibly have a slider two (or the one with 2 pins if possible in qt?) which would control the maximum and minimum  prefetch allowance in % of maximum RAM and or VRAM on the system, with some kind of a minimum limit like it would allow the slider to go below 10% and above 95%, and additional checkbox option would be added whether to use RAM or VRAM or even BOTH for prefetching, there was a plan to add support for VRAM prefetching but not sure what happened to that.
• All the debug stuff on the current "Advanced" tab would be moved to the new "Debug" tab  - Utility groupbox and Debugging groupbox -
• The options under "Other" groupbox in the old Hacks tab should be moved to the "Advanced" tab under "Misc" groupbox and that groupbox naming should be decided, whther to keep Misc or change to Other or spell out Miscellaneous in full.
• The "Other" groupbox in the "General" tab could get a better name, because if it's on the general tab it's means it's more important than being some other thing? These options could be presented as General without any groupbox, positioned a bit differently so it would look okay, not an unnamed groupbox.
  

This is one part of an overall idea from way back to summer 2017 where I was briefly mentioning it, botto guy was interested in it but I never got to explaining it in full, and still not now because I'm trying to find the logfile with all the points I wrote down, there was some idea around the graphics resolution options not being optimal which was changed in-between then and now as others have recognized the same issue but I don't know if it fixed it the way I originall imagined, and also some changes sorrounding some of the sizing options with the "auto adjust window size" option, whether it should be moved to another tab or not, I see some talk about this option right now so I will postpone with my idea and figure out what's going on with that first.

EDIT: Nevermind I just recalled it's not in a textfile but a DRAFT post right here on this forum, lovely feature:




And not even finished it, but the things I said today should override the old ones, I still feel not keeping the Hacks tab named "Hacks"

If it should be kept then I think first some kind of a standard should be figured out which would determine whether something is a hack and each option should go thorugh some discussion with everyone else which things are considered Hacks that would go there.

Then becomes the issue, what do you want to call "Widescreen Hack" then, would it retain the name, or would it just be moved to the Hacks tab, which makes sense from a naming point of view, but not from a functional one, since it's very close to basic settings around resolution, I don't have a problem with moving it tho.

Also I'll reevaluate the draft later and post more updated ideas where my stand is.

EDIT2: I saw and read the reasoning behind the complete removal of the Fullscreen Resolution option, but at the time didn't recall and connect it with my draft ideas so I'll go back and compare the two again, so yeah some of the things I meant were already fixed looks like it, which is a great start.

Essentially "Hacks" are pieces of code that do not replicate or approximate original behaviour but take a shortcut to do things.

Googles definition of Hack:


[color=#222222][color=#878787]informal[/color]
an act of computer hacking.
[color=#878787]"the challenge of the hack itself"[/color]
[/color]

• a piece of computer code providing a quick or inelegant solution to a particular problem.
  [color=#878787]"this hack doesn't work on machines that have a firewall"[/color]
  
• a strategy or technique for managing one's time or activities more efficiently.
  [color=#878787]"another hack that will save time is to cover your side mirrors with a plastic bag when freezing rain is forecast"[/color]
  
  

Thus being able to change the Texture Cache, Bounding Box, Fast depth, GPU Decoding, XFB and EFB changes are all hacks because they are:
1. A quick solution to a particular problem (Slow games)
2. A technique for managing one's time (the computer in this case) more efficiently.

3. They are NOT Enhancements.... (they do not make the game look better than the original)

That is why the Widescreen Hack could maybe get a different name, but although it is called a Hack it is more perceivable as an enhancement on your game/console, although the culling is crap for this enhancement.
Same thing with Per Pixel Lighting... your GC/Wii is unable to do that (and Dolphin in most cases as well because the way lighting works in a lot of games)
Forcing Texture Filtering to always on is an enhancement to your game, but it is still a hack (Quick and inelegant solution to a particular problem namely: blurry textures).
Even being able to increase the IR, change the AA and AF should be considered a hack (a strategy or technique for managing activities more efficiently, why? You have more resources available than you were using originally in the GC/Wii, it would be a waste not to use it for something, thus lets use it for better graphics)

(05-02-2018, 10:43 AM)Renazor Wrote: [ -> ]Now that Qt is default, it's time when this finally comes in.

Considering that technically more things are hacks than just the things included currently on the Hack tab.

• I suggest renaming the "Hacks" tab into "Caches" or "Buffers" or some even more appropriate name for EFB/XFB/Tex Cache (but with new unified system under ubershader settings aren't some of these options obsolete?)

Absolutely not. The hacks tab is very aptly named.

Quote:

Custom Textures would be removed from the Utility groupbox in the Advanced tab and moved to either a new groupbox under Advanced tab or under a new tab.

Custom Textures could be more on it's own rather than just a needle in a haystack

I get where you're coming from here, and I agree that finding how to enable custom textures could be better. I'm not sure if sticking it in it's own group box with two elements is the correct answer. But at the same time we have "misc".... I think an isolated groupbox would be better than the current. But I don't think it's ideal.

Quote: it could possibly have a slider two (or the one with 2 pins if possible in qt?) which would control the maximum and minimum  prefetch allowance in % of maximum RAM and or VRAM on the system, with some kind of a minimum limit like it would allow the slider to go below 10% and above 95%,

I don't believe this is possible to implement in a platform agnostic way.

Quote:and additional checkbox option would be added whether to use RAM or VRAM or even BOTH for prefetching

Pretty sure that's not possible or at least so unwieldy to do that it wouldn't be worth it. On top of that just being confusing to explain in a small description box that the user will never read.

Quote:

The options under "Other" groupbox in the old Hacks tab should be moved to the "Advanced" tab under "Misc" groupbox and that groupbox naming should be decided, whther to keep Misc or change to Other or spell out Miscellaneous in full.

Again, no. They are hacks. I think they belong there.

Quote:And not even finished it, but the things I said today should override the old ones, I still feel not keeping the Hacks tab named "Hacks"

No. They're hacks and users should not touch them unless they know what they're doing. I want that to sound intentionally scary.

Quote:If it should be kept then I think first some kind of a standard should be figured out which would determine whether something is a hack and each option should go thorugh some discussion with everyone else which things are considered Hacks that would go there.

Plenty of bikeshedding goes into that whenever we include something new there.

Now if you wanted to like, get rid of the hacks tab and all the options in it, sign me the heck up.

I'm glad to see more people interested in improving UI/UX.

The version I wrote at this time was based on the thinking from the year old draft, which doesn't have a particular idea about what kind of basis do options get sorted and what kind of meaning is behind Hacks, but that wasn't a stone hard position.

Determining and re-viewing what Hacks should mean and what kind of circumstances an option has to have to be called a Hack then, maybe only a few options or others would need changing and not the ones I mentioned.

The most obvious is the meaning that the implementation behind these options is that they're not implmented correctly/accurately yet, and would be in the future, or never if it's way to much work for too little difference.

You can have something implemented properly as best as it can be, but it would still count as a hack - that's another thing I maybe forgot to point out that from the original game perspective, pretty much everything is a hack, the resolution, the enhancements, right ?
Now the enhancements and other things might truly be proper implementations that hook with the games, but is that really true? If it doesn't hook with some part of original code or internal API and just modifies the area of the memory in a way that officially was never done (similarly to modifying an exe) then it would still be a hack.

So if you go by that, then it's a lot harder to sort things according to original game's viewpoint.

However I don't think that a mainstream definition of a Hack is going to be useful here, it would actually be detrimental, this is a specific field. Guessing the secret answer for a yahoo email account isn't really hacking, for example in security.


EDIT: Here's some of the top few things:

The whole connection betweeen WideScreen hack and Aspect Ratio on the general Tab, never understood it and still don't even tho I keept testing with lots of trial and error and hit the spot last year and kept with it ... as mentioned a rename could help, but some kind of a note too - For me, I had to use widescreen hack to get the results I wanted, but because it's a HACK it has the "don't touch it unless" connotation. Then you have the Aspect Ratio on the Wii tab on the Config window, wait what?

Then I would move the Internal Resolution over from the Enhancements to the General under Basic - Yes it's an enhancement, but it's a BASIC enhancement, right, so language/semantics wise it would all be fine, the Enhancments tab would keep holding other enhancements. While it's technically an internal resolution, that's the main one that dolphin deals with, as it was said, it's not a PC game it's trying to emulate, so it would be justified it has it's own logic with this too.

Speaking of IR and the Wii Config tab, you have PAL60 or EU-RGB60 Mode ... how is that counted with IR then, is that compensated? Wouldn't all the calculations change if the x2 x3 x4 IR setting is based of different native resolution ?
There should be some kind of a note or some kind of indicator (* mark) that PAL60 is enabled, these two options seem far apart, but if my hunch is real then the proper fix would be the actual IR options would be renamed to reflect that when PAL60 is used.

Reading about the Fullscreen Resolution in a recent bug ticket https://bugs.dolphin-emu.org/issues/11073 and the talk on the PR https://github.com/dolphin-emu/dolphin/pull/6196 make me think, judging by the fact the removal was because it causes user confusion, what if there could be semi-sneaky checkbox option somewhere which would definitelly keep most users away from enabling it, "CRT TV Output" or "CRT Monitor (legacy)" or "Legacy CRT TV Output" or "Legacy Display (CRT)" ... and only after applying that the option to set fullscren resolution would appear in another tab like Advanced or something, not in the General tab where this checkbox would be for example, so it kinda looks like it does nothing and wouldn't be obvious so they would click it out of curiosity, but disable it back again probably. And what I mean by appear is that it literally changes the GUI, so if you never enable it and look around, you'd never see it, but that's a question if it can be done cross platform.

(05-05-2018, 11:44 PM)mstreurman Wrote: [ -> ]1. A quick solution to a particular problem (Slow games)
2. A technique for managing one's time (the computer in this case) more efficiently.

3. They are NOT Enhancements.... (they do not make the game look better than the original)

That is why the Widescreen Hack could maybe get a different name, but although it is called a Hack it is more perceivable as an enhancement on your game/console, although the culling is crap for this enhancement.
Same thing with Per Pixel Lighting... your GC/Wii is unable to do that (and Dolphin in most cases as well because the way lighting works in a lot of games)
Forcing Texture Filtering to always on is an enhancement to your game, but it is still a hack (Quick and inelegant solution to a particular problem namely: blurry textures).
Even being able to increase the IR, change the AA and AF should be considered a hack (a strategy or technique for managing activities more efficiently, why? You have more resources available than you were using originally in the GC/Wii, it would be a waste not to use it for something, thus lets use it for better graphics)

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.

(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.

Interesting and well explained.

Seems to me that it's a good idea to treat game-breaking/stability accuracy different from purely graphical accuracy, which would only affect the looks, not the core.

Technically the graphics improvements also affect accuracy if we put it all in one bin, but if it's less accurate only graphically but better looking and not affecting core then that's pretty good. Such options that purely increase graphical fidelity at the cost of performance without causing gameplay/core loss of emulation accuracy/stability should too be found out which of them are in this category. Ofcourse this isn't some important thing, but it would be a lovely chart to have lying around, if the thing ever materialized it could be put into the GUI one day, in some fashion, or just as a Docs PDF and/or wiki.

Ubershaders could be considered purely graphical accuracy, right? Things may look messy, but it wouldn't cause a crash or and gameplay change - to how extent is that true would you say? Even confirmable, I'm afraid of tiny differences which would need deep testing.

(05-08-2018, 06:05 AM)Renazor Wrote: [ -> ]Interesting and well explained.

Seems to me that it's a good idea to treat game-breaking/stability accuracy different from purely graphical accuracy, which would only affect the looks, not the core.

Technically the graphics improvements also affect accuracy if we put it all in one bin, but if it's less accurate only graphically but better looking and not affecting core then that's pretty good. Such options that purely increase graphical fidelity at the cost of performance without causing gameplay/core loss of emulation accuracy/stability should too be found out which of them are in this category. Ofcourse this isn't some important thing, but it would be a lovely chart to have lying around, if the thing ever materialized it could be put into the GUI one day, in some fashion, or just as a Docs PDF and/or wiki.

Ubershaders could be considered purely graphical accuracy, right? Things may look messy, but it wouldn't cause a crash or and gameplay change - to how extent is that true would you say? Even confirmable, I'm afraid of tiny differences which would need deep testing.

I don't think you get what I said... You can not determine the impact of a certain setting on a game. It differs from game to game.

Ubershaders are not a "accuracy setting" per se, the only thing it does is work around a limitation of the PC. The output is exactly the same for all settings (except for Skip drawing).
The same for back-ends, the output should be exactly the same across all API's.

That is why there is the Compatibility list on the website: https://dolphin-emu.org/compat/

I was having Metroid Prime 3 in mind with Ubershader Skip Drawing yes, it doesn't look accurate but there's no obvious gameplay changes or emulation stability issues afaik.