Revert "VideoCommon: rename efb2tex and efb2ram"

[Stevoisiak]

Reverts this commit

Done at the request of MaJoR1

[MayImilae]

Alright! I asked for this PR so we can have the discussion that was needed before PR2089 was merged. This is NOT about bringing Disable EFB Copies back! This is about the UI change that followed it, and ways to make it as good as can be.

So, here are my problem with the UI changes of PR2089:

First up, I don't like how it takes the most important option in the tab and hides it amidst a bunch of other things. EFB to Texture and EFB to Ram is so commonly changed that a GUI key was expressly requested and added for the option! Since it is about balancing the key difference between how PCs and GameCube/Wiis operate, it is the primary way to balance compatibility and speed. Hiding it is not good from a UI usability standpoint.

The "skip" language is problematic. There's a GUI concept of "consistency of language". Basically, if you use one term for something that's ok, then something else that uses that term is ok too. I'm worried about how users will think of "Skip EFB access from cpu" when "Skip EFB copies to ram" is normal and ok. In fact this was a problem with XFB as well, but if you disabled EFB Copies 99% of games show nothing so they turn it off immediately (and this is part of why I'm glad efb copies disable is gone!). We have had numerous problems on the forums where people disable Skip EFB Access from CPU and then complain about things being broken since it subtly breaks things. By using the same language (and being bundled with benign options) this just makes people more likely to try it!

Lastly, EFB to Texture and EFB to Ram are very common language elements. It will require user retraining in a progress report. Furthermore, it throws off all of our documentation on the wiki and elsewhere. Guess who has to do all of those things! It's doable, but that doesn't mean I like it. :P

I like the radio buttons, since it was very simple and everyone is used to that. But no one else seems to like them so... At the very least, I'd like to see a change in placement so the most important option in the tab is easily discovered and to avoid using the word "skip".

[JMC47]

I disagree for a few simple reasons.

I can't pretend to know what the most accurate way to write EFB2RAM/EFB2TEX is, but let's look at precedent. In Dolphin, for Skip EFB Access to CPU is a hack. Why wouldn't Skip EFB Copies to RAM be the equivalent hack for EFB2Texture.

Secondly, shouldn't our goal be to have the hacks menu completely devoid of having enabled when no hacks are on?

Thirdly, I think with proper explanation, this option is simply better. If it's on, there's a hack enabled, if it's off, there's no hack. I'd love for XFB to be handled like this once the regressions in virtual are fixed.

[MayImilae]

The goal of eventually losing EFB to Texture is a great one, but that doesn't change the fact that users are going to be using it primarily for years and years to come! It should not be bundled and buried like this. This is a normal setting users have to have access to.

And why no commentary on the text? sigh Skip is a definite problem, and there has to be better wording. Just because they are both "hacks" doesn't change that we need to streamline user behavior with UI strategies!

[JMC47]

Sure, Skip can be replaced by something, but what do you suggest that's as accurate?

[MayImilae]

"Store EFB Copies to Texture" in it's own box for obviousness would fix the problems I outlined. I still think radio buttons in their own box is better though, but that works.

EDIT: degasus suggested adding "only" to this. So that would make it "Store EFB Copies Only to Texture" or "Store EFB Copies to Texture Only".

@pauldacheez

[degasus]

about "to texture", I'd like "to VRAM" or "as texture" more

or based on MaJoR suggestion: "Store EFB Copies in VRAM only"

[Stevoisiak]

Superseded by #2156

[neobrain]

For what it's worth, an alternative approach to naming this option might be dropping the "VRAM<->Texture" crap altogether and instead using something like "Use EFB copy shortcut", because that's what the optional code path does: It's taking a shortcut by storing EFB copy regions directly in a GPU texture, instead of storing it in emulated RAM and decoding it to a GPU texture upon usage.