mrvux / dx11-vvvv

DirectX11 Rendering within vvvv
Other
71 stars 71 forks source link

Adding global packs location for shader includes #364

Closed tebjan closed 4 years ago

tebjan commented 4 years ago

beta39 will have a new (optional) location to store packs in order to not force the user to install it for each version again.

it will be in 'User\AppData\local\vvvv\beta_x64\packs'. adding this search patch to the pack shouldn't be too complicated. @microdee identified the locations already:

this is where VVVV.DX11 handles includes: https://github.com/mrvux/dx11-vvvv/blob/368aabdf73bee27ee156e6bfa48dc318768f0643/Core/VVVV.DX11.Lib/Effects/DX11ShaderInclude.cs#L31

and this is where FeralTic actually tells the include handler the system include folder path: https://github.com/mrvux/FeralTic/blob/82a85ed60eee1ddce6d556c6547dd9c2c4054bad/Core/DX11/Shaders/DX11Effect.cs#L37

and this is where multiple path search for the system includes can be implemented https://github.com/mrvux/FeralTic/blob/82a85ed60eee1ddce6d556c6547dd9c2c4054bad/Core/DX11/Shaders/DX11Effect.cs#L77

I guess

what would be the best way to implement that feature? are you willing to add it? or should we make PR for that?

velcrome commented 4 years ago

is there a way to query the packs directory vvvv currently uses?

tebjan commented 4 years ago

@velcrome there is two dirs then, vvvv/packs and appdata/local/vvvv/packs. is that your question? anyway, we decided to remove this feature from beta for now, as we have to clear more things up. we'll add it to previews after the beta39 release again.

mrvux commented 4 years ago

Last commit allows additional path, which is set to user data (depending on 32/64 bits too)

tebjan commented 4 years ago

thanks a lot! we've just had a look at it and thought that we can provide the path via the host since it can also be _vvvv\beta_previewarch ... i'll let you know once we have that.

mrvux commented 4 years ago

yes only issue I have with host is that it will break compat on previous versions, would need to see if i can wrap the call in a try catch so it does not break that (might just get a methodnotfound, which is ok as i would just ignore the folder in that case) will need to test it

tebjan commented 4 years ago

@mrvux we had another look at this and thought that in the end a global packs folder might cause more problems than it would really solve. for example, for future vvvversions, it is better to not have old packs laying around that might potentially break the new version or don't work anymore.

so sorry for the fuzz... you can revert that commit and pretend it never happened. :)