Skip to content
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

GUI: remove presets 4,5,6 #4882

Merged
merged 1 commit into from
Oct 7, 2021
Merged

GUI: remove presets 4,5,6 #4882

merged 1 commit into from
Oct 7, 2021

Conversation

Mrlinkwii
Copy link
Contributor

Description of Changes

removes presets 4-6 and leaves presets 1-3

Rationale behind Changes

Preset 4-6 cause more issues than they help , so getting rid of them stops user error and user headache

Suggested Testing Steps

make sure the slider for the presets dont crash

@github-actions github-actions bot added the GUI/WX label Oct 6, 2021
@avih
Copy link
Contributor

avih commented Oct 7, 2021

FWIW, personally I don't think it's a great idea to remove such user control.

Issues related to performance and not-fast-enough hardware were and are always present at the PCSX2 forums. There are definitely cases where the higher preset levels do more good than bad (especially subjectively), and allow squeezing some usable gaming speed from an otherwise weak system (at some cost for sure, but many times the cost is subjectively acceptable).

There are already warnings and colors. The implementation is trivial and removing those levels doesn't make the PCSX2 code less complex. It's true that it does remove a potential footgun, but it it's also definitely true that there are use cases where it can help, and removing them simply reduces the choice which the user has, and IMHO that's not great.

@refractionpcsx2
Copy link
Member

refractionpcsx2 commented Oct 7, 2021

There are already warnings and colors.

If you'd done any support in the last 5 years, you'd have realised nobody pays attention to those. We've had people coming in complaining their emu is slow just to find they've cranked the EE slider up to +3 and ignored the red text that tells you it makes it harder on your system.
The point in removing them is to stop it being so easy for people to whack it up to the "Extreme" preset, cos it sounds cool, right?? It's just a headache for us, plus it causes more problems than it solves. It's not like they can't still mess with the speedhack sliders, but now they will have to do it more controlled and hopefully under our recommendation.

@tadanokojin
Copy link
Member

Yeah I mean this seems to be a running meme with the old guard. Every time we try to make something easier to use, understand and harder to break there's someone in the background who insists on terrible UX and supporting low power machines to the point of absurdity.

I gotta be honest I don't understand this commitment to continually defending what is quite obviously giving our users worse experiences and just ignoring the realities on the ground for the sake of keeping something that really doesn't benefit much anyway.

I'd rather be honest and say "hey, you can't really run games on an toaster, here's our hw requirements" than act like anything beyond 3 should be a preset when any reasonable person does and should have the expectation that presets should not be consistently breaking shit.

@RedDevilus
Copy link
Contributor

RedDevilus commented Oct 7, 2021

I have had more luck with frameskipping (yes i know , it's hacky and you can go overboard) a bit on my older laptop then i ever did with the presets. Especially now that the behavior has changed because of VU timing changes and the average computer should be able to with preset 2 or 3.

Why preset 4-6 fail in is that it doesn't give universal benefits, hell it could even make your experience worse (lower performance, TLB misses, other breaking changes)

For one a game could like -1 cyclerate, another could like +3 or +1 , Shadow of The Colossus needs EE cycleskipping but most games don't benefit from it.

@lightningterror
Copy link
Contributor

The sooner it's removed the better.

@avih
Copy link
Contributor

avih commented Oct 7, 2021

Yeah I mean this seems to be a running meme with the old guard

It doesn't exactly happen every other day - that I can tell (feel free to prove me wrong), so this statement sets a tone for the message while being completely irrelevant.

Anyway, I'm only speaking for myself, and not representing any kind of "guard", so it would really be more productive if you just drop the memes and keep your statements on point.

As a user and developer, there's a big distinction between "great experience out of the box" and "flexibility to solve problems which the developers don't face, but some users do", and these two things are not necessarily mutually exclusive, especially when maintaining both doesn't add meaningful maintenance burden.

I do also see the value in removing footguns, including in support (though this could fire both ways), but maintaining these option has a lot of value too, especially if it's obvious to the user that from this point they're on their own, and the developers cannot guarantee some standards of quality which are otherwise expected - but for many users it's a fair tradeoff, even if many other users would never need to use it.

@RedDevilus
Copy link
Contributor

RedDevilus commented Oct 7, 2021

Thing is that's assuming it helps, in most cases it doesn't.

Enough people have issues on 4-6 because they think it's more speedy or offsets the need for more powerful hardware and no it won't. It's a band-aid solution unless it was game-specific which it's not.

Just compare latest dev build and stable you can see it works less than before because of accuracy.

@avih
Copy link
Contributor

avih commented Oct 7, 2021

Enough people have issues on 4-6

Absolutely. It's definitely outside the "recommended" or even "good" for many cases, and has always been the case.

because they think it's more speedy or offsets the need for more powerful hardware

Yup. Users never read docs and ignore warnings. In any program - users are the hardest problem to fix ;)

That being said, it's orthogonal to the argument that it could still be useful to some other users.

it works less than before because of accuracy.

That's a fair argument. If indeed there are barely games which can benefit from it for users with weak hardware, and/or if it now has more issues than in the past (like crashes or general bad behavior), then keeping it is indeed not a great idea.

These days I wouldn't know, because I do have fine HW, but in the past it was very useful to me (that's the reason I added the presets system - to make it easier for "normal" users to coordinate/tune a complex set of settings split between different configuration places using a simple slider).

So the question really is: are there (more than few) users who use these presets for some games and find them useful?

@JordanTheToaster
Copy link
Contributor

Enough people have issues on 4-6

Absolutely. It's definitely outside the "recommended" or even "good" for many cases, and has always been the case.

because they think it's more speedy or offsets the need for more powerful hardware

Yup. Users never read docs and ignore warnings. In any program - users are the hardest problem to fix ;)

That being said, it's orthogonal to the argument that it could still be useful to some other users.

it works less than before because of accuracy.

That's a fair argument. If indeed there are barely games which can benefit from it for users with weak hardware, and/or if it now has more issues than in the past (like crashes or general bad behavior), then keeping it is indeed not a great idea.

These days I wouldn't know, because I do have fine HW, but in the past it was very useful to me (that's the reason I added the presets system - to make it easier for "normal" users to coordinate/tune a complex set of settings split between different configuration places using a simple slider).

So the question really is: are there (more than few) users who use these presets for some games and find them useful?

So they can untick the preset box and set it manually the ability to change these things manually isn't being taken away just the misleading presets.

@avih
Copy link
Contributor

avih commented Oct 7, 2021

So they can untick the preset box and set it manually

That's also a good argument. Does it still hold true?

And maybe more importantly, is it likely to keep such options which can benefit users with slow hardware but in general are not recommended?

@refractionpcsx2 refractionpcsx2 merged commit 296911b into PCSX2:master Oct 7, 2021
@Mrlinkwii Mrlinkwii deleted the presets branch October 7, 2021 21:15
@avih
Copy link
Contributor

avih commented Oct 8, 2021

So they can untick the preset box and set it manually

That's also a good argument. Does it still hold true?

As it turns out, it doesn't hold true - #4883 (comment)

Because right after removing the presets, the manual options to help those with slow systems are also removed (this is one option, but the point is clear).

And that's after a user explicitly gives an example of a game that's only playable on their system with this speed hack.

Of course, it could still be the case that this option is very bad in general (crashes a lot, introduces other bad bugs) - I don't know that, but THAT would be a good reason to remove it. But judging by this #4883 (comment) at least for this game it's apparently useful. My guess that it's not the only game, but it's just a guess.

Anyway, I'm not going to continue the discussion because my point was already expressed, and so has yours.

But do consider not throwing users with old systems under the bus without "proper" reason (like bugs, code complexity, etc).

Over and out.

@refractionpcsx2
Copy link
Member

refractionpcsx2 commented Oct 8, 2021

Skipping 3 is rarely useful, if ever, it causes dramatic internal framerate problems, saying it makes a game playable is somewhat of a stretch, but it is rarely (if ever) useful over skipping 2, it's usually diminishing returns of usefulness after that point.

Also if a user has an old core 2 that doesn't even meet our minimum requirements and they want good performance, 1.7 is not going to do them any favours and they are best served using an older version until they can upgrade.

The whole notion we have to hold on to the past and terrible hacks because somebody with an archaic machine might want it is ridiculous. The project needs to move forward to improve and holding on to old jank from the past to satisfy a few users is not worth our time or the technical debt it incurs. Maybe not so much the skipping but it is considered an extremely harmful setting and we're moving away from having settings which are too harmful in the name of speed. We have the reputation of being the emulator full of hacks for reasons like this, and this is a reputation we'd like to shake off.

@dio-gh
Copy link
Contributor

dio-gh commented Oct 8, 2021

flexibility to solve problems which the developers don't face, but some users do

But if this is a frequent problem on help channels, then clearly the number of users who use these levels despite not needing it surpasses the number of users who do need it, am I wrong? Does this not drive it home that it's a "footgun", that instead of benefitting users, it leads them astray instead?

And why do you discuss another PR here? I get that it's related, but still. This removal here is purely cosmetic, whether further levels are cut from different sliders in the suspectable future, that doesn't belong here.

@tadanokojin
Copy link
Member

I told you it's a meme.

It's a completely irrational commitment to the impractical disguised with concern trolling and completely ignorant to the reality on the ground. If there was a hack that made Jak 3 run on a PIII but kicked the user in the dick every 10 minutes avih would be here arguing that we should keep it and hand waving away any and all arguments about user experience because he knows a guy who doesn't mind the pain in his crotch.

Fortunately, we have the benefit of hindsight on this now. While other emulators continue to focus on setting expectations, ease of use and realistic requirements our commitment has been to finding ways to make PCSX2 run like shit on a potato and our reputation, rightfully, suffers because our interface is overly complicated, filled with hacks and special options that break things to benefit a fraction of usecases. And when they tell us that the interface is complicated and difficult to understand we hand waved their problems away as insignificant and blame them for it to boot.

It's time to stop. If you want to sit here and pretend UX isn't a "proper" reason to do things then I guess you're welcome to do that. The rest of us have decided that the old way of doing things sucks ass and it's time for a change.

@avih
Copy link
Contributor

avih commented Oct 8, 2021

And why do you discuss another PR here?

Because the suggestion to use manual option was here, and the reply to that suggestion needs to refer to elsewhere. This does not warrant moving the discussion to elsewhere.

If you want to sit here and pretend UX isn't a "proper" reason to do things then I guess you're welcome to do that.

If you want to sit here and claim that you're a shitty developer, then I guess you're welcome to do that.

Oh, wait, you didn't actually claim that. Well, guess what, neither did I pretend UX is not a good reason to do things.

But since you were guessing what I pretend (that's kinda mind bending), then stop guessing. I'll tell you that I think UX is not only important, it's super important. And making sure UX is good is a very valid reason for many things. Default values are also very important for the same reason - UX. Because we all know what users are like, and we all agree that we can't fix users.

But, assuming some option is still useful (and that's a big if, judging by the replies above) the solution to the (very valid) UX problem is not necessarily to remove (this) flexibility altogether.

Sure, removing the flexibility it's ONE possible solution, but if you asked the users for which this flexibility is important, I'm pretty sure they'll find is a bad solution.

So IF you think this option is still useful to some users AND IF you care about those users, then removing the flexibility is doing them a disservice.

I can't answer the "if" questions for you, but just in case you do think the option can be useful and you do care about them, then you get the point.

@refractionpcsx2
Copy link
Member

Giving users the choice to cut their own fingers off is an option, but why should we offer them that solution when it's only to the determent of most people (possibly even themselves) and makes our life more difficult? You can add a lot of "flexibility" but it also adds complexity, confusion and bugs along with it.

@avih
Copy link
Contributor

avih commented Oct 8, 2021

makes our life more difficult?

As I said earlier, this is a very valid reason (support). I can't judge this for you and I can't balance the factors for you.

You can add a lot of "flexibility" but it also adds complexity

As I said earlier, that's very true in general, and definitely a valid reason to not add flexibility, and vice-verse - removing flexibility to make things simpler can be a great reason.

But as far as I can tell, not in this case - of simply removing support for some option values without actually making anything simpler at the code (that I could notice).

confusion

The existing solution to the UX problem of discouraging users from using not-recommended values by adding warning/colors is apparently not enough. I thought It is enough, but you claim it's not, and I believe you.

Finding a better solution is indeed effort, which I can't ask anyone (but myself) to make.

and bugs

100% agreed. If it only adds bugs without any useful value then it should go away yesterday.

All of it comes down to the developers deciding what they care about, and how they balance the values with the costs. I can't make decisions for other people.

@tadanokojin
Copy link
Member

We made the decision. You're just bikeshedding about it for whatever reason.

@avih
Copy link
Contributor

avih commented Oct 8, 2021

We made the decision.

That's obvious. But decisions can be reverted if there are factors which were neglected originally.

If none were neglected, then sure, there's nothing else to discuss.

@tadanokojin
Copy link
Member

I've already explained to you that we don't wish to continue with things we know aren't working and frankly I'm kind of sick of bickering about whether we should keep or add hacks. The answer is we shouldn't. We should making efforts to removing them. Is everyone going to win in that transaction? No, but it's time to start working to a better future.

We have hardware requirements and we want options and settings that represent a commitment to those requirements and we're no longer interested in presenting users with options that ignore that expectation in favor of more increasingly hacky and broken behavior. You can't fix this problem by putting a bunch of text on it, or having defaults, or whatever you have in mind. The issue isn't that we need to inform our users about the dangers of a given option, it's that we're presenting them with something so broken at all. It's that we're even pretending that's a good idea and grasping at straws like pgert's comment on another PR about a system with DDR2 and SSE4.1 and that I have no other information about isn't making a strong case to the contrary.

At some point you have to draw a line. For us the line is sticking mostly harmful options in the emulator that give the illusion of performance in a few games for a few configurations but completely breaks everything else. Sure, flexibility is great but there's a distinction between flexibility that gives users meaningful control and shit that is just broken most of the time and doesn't need to exist. Not everything we decide to remove needs to be removed because of a bug, or code complexity or whatever you consider to be "proper" reasons. Sometimes things just don't represent what we are trying to accomplish anymore and it's time to move on regardless of those things.

We've decided we don't want to do these things anymore and you've decided to continue to defend doing them despite years of pretty undeniable hindsight on this. Your values don't represent what the project is trying to accomplish. So if you weigh this commitment to hacks and giving users control over stuff that's broken, fine. But I don't feel the need to keep arguing about it because as far as I'm concerned the decision isn't controversial.

Instead, we're ready to provide a meaningfully better product to our users that's easy to understand, configure and use and provides them with features that can better their experience instead of workarounds that don't.

Everyone has already pointed all of these things out to you. There is nothing else to discuss. We've given you the information, you can take it or leave it as far as I'm concerned but I'm not going to endlessly keep wasting energy trying to convince someone who's too busy trying to get up to speed on what these settings do and fake storming out of a discussion just to come back to bicker some more.

Every other project has learned from our mistakes, it's time we learned from them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants