The best way to actually get feedback for this is to just open a PR. If you're still interested in the the change, please just do that. Worst case scenario is that we close it.
Worst case scenario is that we close it.
You maybe missed that part where other peoples time still mean something. Keeping PR up-to-date with constantly changing code, you know ...
In this case I didn't know is there any pending code which will address or rewrite parts of this patch, so before doing something I decided to ask if it worth it. Given that it is not critical but "nice to have" (maybe) code changes.
So, yes, this is your "Worst case scenario" -- I already forgot about it and you closed it.
If I am honest, I think what we have works fine for now.
I tried this with old dxvk native and it was... hard to make distinctions sometimes.
DXVK_PLATFORM_APIx1 2022-08DXVK_USE_VRx1 2022-08DXVK_WIN32_APIx1 2022-08DXVK_WIN32_BUILDx1 2022-08
#ifdef _WIN32in source code used in many different meanings, so I tried to clarify this a bit.This may help not default platforms and/or combinations like winelib.
DXVK_WIN32_API- use native windows APIDXVK_WIN32_BUILD- native or cross windows buildDXVK_PLATFORM_API- use platform APIDXVK_USE_VR- in case of default dxvk build it can be set unconditionally or used for optionally disable VR supportIn addition default dxvk build should set
DXVK_WIN32_APIandDXVK_WIN32_BUILDand optionallyDXVK_USE_VR, native build should set onlyDXVK_PLATFORM_APIand "mix" could use onlyDXVK_WIN32_API.If this acceptable I can do Draft or PR for further discussion, or feel free to use/modify attached example
dxvk-2.0-win32-def.patch.txt