Welcome, Guest.
Username: Password: Remember me

TOPIC: v4 drag-to-slider changes should be reversed

v4 drag-to-slider changes should be reversed 2 weeks 4 days ago #1

I see you changed the 'drag' widget to 'slider' in a lot of shaders, for the v4 release. This is fine for some but e.g. in the shaders I made, I deliberately tweak them to have great UX, so I specify ui_step values where I can. Using 'slider' now has a downside here: 'slider' has a step of 0.05, which is pretty rigid in some situations and as 'slider' doesn't have support for ui_step, it makes using the shaders less ideal.

What I understood from the v4 thread was you'd reverse the auto change from drag to slider and instead would do it on a shader by shader basis but it seems you simply replaced 'drag' with 'slider' in most shaders in one search/replace. While this is totally understandable, it's time consuming after all!, this leads to problems with both v3 users who get the shaders automatically pulled from the repo (and which don't work) and with v4 users who now have sliders instead of drags which give less precise UX.

I think a different approach is better, one where either the code for 'slider' is adjusted so it does support ui_step or to auto change 'drag' to slider IF a ui_step value is set to a value > 0.05 so it doesn't matter. (See my reply in the v4 thread about this: reshade.me/forum/releases/4772-4-0?limitstart=0#30695).

What is the best way to deal with this going forward? As the current state of the shaders more or less implies that over time shaders are converted back to 'drags' where people want them to be drags again as the UX of sliders isn't cutting it anyway. IMHO a change to automatically deal with this inside reshade so the shaders can be kept as they were before (so with drags in the code) is preferable, so v3 users pull shaders that work and v4 get sliders when it doesn't matter.
Last Edit: 2 weeks 3 days ago by OtisInf.
The administrator has disabled public write access.

v4 drag-to-slider changes should be reversed 2 weeks 3 days ago #2

Why alter the shader in the first place since it breaks backwards compatibility (Say anti-cheat software for games no longer being updated requiring removing said software or using a older version of ReShade.) and not just do it as some setting in ReShade where one value can be the old behavior and another value can use the new one?

Just my thought about it, guess if it was that easy to alias a value into two distinct behaviors it would have negated the need to alter the shaders in the first place.

EDIT: Hmm maybe not, preprocessor definition perhaps but unless it could be per-shader a global change like that would improve some shaders configuring and hinder others depending on how the author set up this to begin with. Maybe?
Last Edit: 2 weeks 3 days ago by JBeckman.
The administrator has disabled public write access.