Is the SweetFX incompatability fixable?

[ultimatespirit]

Hi Ipsusu!

First of all really quick, wanted to let you know how much I've appreciated your shaders/presets and especially your quick response to the gshade mess + general open source support. Really just a great person.

With that out of the way, I wanted to ask if the SweetFX incompatibility with a default installation of ReShade 5.6 + all optional shaders is completely unavoidable, or if that is something you believe can be worked around or fixed.

The reason I am asking is that I've noticed the post-gshade community of presets/shaders to seemingly be going down two or three different vaguely incompatible paths. Some assume reshade-shaders/Shaders to be a port of what gshade-shaders/Shaders had, potentially with one of several compatibility patches tossed in, others do as your setup does with asking for a fresh ReShade-5.6 install without any of its extra bundled shaders, and then some ask for the same but with all extra bundled shaders installed. Unfortunately, however, the available shaders and overall directory structures of those three setups are not necessarily mutually compatible, especially the version with all shaders of ReShade installed, which relies on subdirectories.

It seems this means the set of preset developers may fracture in terms of mutual interoperability, where if you wish to use IpsuShade you cannot use a preset/shader assuming all shaders were installed, or may get weird behaviour from a preset assuming gshade files only, or breakage of IpsuShade itself from compat shaders (for example I've found that the full shader fixes distributed as part of the original Rika migration guide will break MXAO for this shader, without getting the observed doubling up of the options in the preset menu, if used with a migrated gshade-shaders folder).

Now, to an extent it seems this issue was unavoidable, many presets seem to use slightly different versions of the same files and ask those to be copied directly into the same locations, so overwriting issues will come about eventually. However, the base assumed / asked for install seems like it could be a good starting area for trying to converge the community back to a somewhat mutually interoperable sane starting setup. I do not know much about the shader design itself however, so I do not know how feasible it is, so I wanted to ask if it's possible to get IpsuShade compatible with ReShade 5.6 w/all optional shaders installed (which seems to be a useful starting point for community convergence, and also the most strictly incompatible directory layout by default), or if you think it's even worth doing / trying to get some convergence on disparate shaders (I know nothing about how big a goal or not it is for the different makers to be interoperable).

Thank you and apologies for having such a long explanation / ask, and again really appreciate all you do!

[ipsusu]

Hello!

Thank you for asking this. Please see below my rambly reply written through me skimming sections of your question.

I think I've gotten slightly confused actually. I think SweetFX should actually be fine to install through ReShade alongside my presets as there is no shaders that I provide in my IpsuShade pack that overlap.

Before when I said SweetFX, I actually meant OtisFX, as that is the one that installs a MultiLUT that will mess with my presets. I'm going to update the guide now to note this, but I think I'll still advise a barebones install just for sanity sake.

However, more generally there is an issue with compatibility with ReShade default versions of shaders vs ones that I provide in my own pack. My presets were first created with GShade and use custom hardcoded values in shaders like MultiLUT, which all the colour in my presets comes from. They'll be compatible with both ReShade and GShade if I continue with my current setup, but if I change to ReShade vanilla MultiLUT, I'm going to have issues with anyone hanging around on GShade or using an upcoming release. I don't want to punish any users for choosing the program that suits them best.

On the issue of compatibility and subdirectories, I don't know if there is a best course of action. I can make my stuff ReShade standard with subdirectories but then it'd break using GShade standard stuff. Everyone has their own weird quirks to their install. Some use a \reshade-shaders\** path, some hardcode the specific folders. I think people just need to understand the program and have clear troubleshooting steps for when stuff goes wrong.

The issue with mutual interoperability is exactly what GShade was designed to avoid, but I think if we assume the most common user would be a GShade user who has migrated their /gshade-shaders/ over to ReShade or has downloaded a archive of this folder, adopting the "standard" of GShade shaders should allow for the most common user to still have interoperability.

Apart from the qUINT shaders (which GShade itself had a license agreement to distribute the latest versions of), all of the shaders in my repo are the GShade standard releases. And, the majority can be overwritten with their ReShade vanilla versions (and may be identical).

I've not tested the Rika shader fixes, and I'm not quite sure what they really need to be fixing, everything basically works fine under ReShade apart from certain features of FFKeepUI which relied on custom GShade code.

But yeah on the issue of getting IpsuShade compatible with ReShade 5.6 w/all optional shaders installed, I think guides shouldn't just advise people to download all the shaders unless people are trying to make their own presets. Having people download the shaders on install means they're frozen in time at the point of install. If someone has the shader from an install this month, but next month they want to install my presets which uses a function only avaliable in the updated version of the shader, it's just going to be even more confusing.

Essentially, this repo is designed to work as simply as possible on it's own, while providing as much compatibility with other presets and GShade as possible. If I change everything to adopt a new standard, stuff will break elsewhere. Ideally I'd want someone to make an automated preset installer that uses standardised shaders, which would cultivate an ecosystem of presets using the same shader variants like GShade did.

I don't think it's worth me taking any action right now. I'll wait a couple of months to see what people are using and how the XIV ReShade/GShade scene has progressed. If you want my prediction, I expect people to have just stuck with their ported GShade installs to ReShade, and people will stop thinking about it. They're not being forced to update anymore and if it ain't broke, don't fix it!

[ipsusu]

I'll keep this issue open just in-case anyone else wants to suggest anything, and I guess the issue isn't solved, per say, either!

[ultimatespirit]

Thanks for the great explanation, and certainly understandable to aim for and keep to the highest compatibility / minimum setups. It wouldn't surprise me if within a few weeks / months a proper open source tracking fork of ReShade occurs that just keeps track of those common shaders as you say.

What led me down this path in the first place was that I've been trying to document requirements for the ReShade setups for Linux. Since we to an extent have to just build our own tools or guides around finangling whatever Windows specific (in setup tools / installer tools) things come out. Ironically, it sounds like the setup on Linux will be able to more easily stay up to date than what the Windows ReShade situation seems to be, since the most sane setup so far seems to just be exactly git clone-ing the shader repos ReShade installs and managing via those. So updates will be as simple as a pull when needed, but that's definitely not the sort of solution you'd be able to just toss onto a random Windows computer and expect to work though haha.

Thanks again and all the best Ipsusu!

[ipsusu]

If you'd like, I can create a version of my presets that is intended for a ReShade install that works with just git clones of the Shaders that I use? Hopefully shouldn't be too much effort. I'll still recommend my own options, but providing this as an option is only a benefit (as long as I don't confuse users on which option to pick).

[ultimatespirit]

Hey, if you can get that working and it's not too much of a burden on your / too confusing, it certainly sounds helpful! I don't know what the statistics would be like on people needing / using that though so seriously if it's too much a maintenance burden somehow (I know nothing about shader complexity in this case haha) don't feel pressured or anything!

[ipsusu]

It'll be on my To-Do list for sure. I'm a bit burned out of ReShade tinkering for now but give me a week and I'll get on it. It may have slightly different features than my current presets, but as long as I can get the MultiLUT working with the OtisFX vanilla version, it should be possible and more or less the same functionality. Thanks for your support!

For people using it, I think it just having the option available is good enough for me. As long as one or two people get long term use out of it, probably was worth my time.

For maintenance, it shouldn't be too much of a concern since I think every shader is backwards compatible with any settings I make now, even if they do get updated. Even if I only get round to making my Gameplay / Questing presets, it should still be useful!

[ipsusu]

Okay, been more than a week since I've been doing other stuff than ReShade work, but when I get back around to ReShade stuff I'll work on this too!

[ipsusu]

This is still on the To-Do list, I haven't forgotten! Sorry!

[ipsusu]

Finally, implemented in ipsuShade v2.0.0. Apologies for the delay! Thanks for your support.