MINGW-packages
MINGW-packages copied to clipboard
msys2
New package - mingw-w64-efxc2.
My program does not require that the compiler .DLL be in the same directory as the .EXE. In addition, the program does offer some options that fxc2 does not offer. I also made sure that the output would match some of Microsoft's code where the header defines something as an array of byte instead of an array of signed char. It also has better parsing than fxc2 did because it uses the patch ( https://github.com/mozilla/fxc2/pull/3 ). The program is now compiled with -MUnicode allowing paths to non-US ASCII. Another advantage over fxc2 is that is better maintained since I do that.
The program is based on fxc2 but it is not a mere recompilation with a minor tweak.
I see, thanks.
I also found some patches in VLC: https://code.videolan.org/videolan/vlc/-/tree/master/contrib/src/fxc2
I am still looking at those patches to see what can be integrated. But quite a bit looks like the source-code I found earlier or the author did something similar to what I did. The program I wrote uses CMake instead of the standard GNU make.
https://code.videolan.org/videolan/vlc/-/blob/master/contrib/src/fxc2/0001-make-Vn-argument-as-optional-and-provide-default-var.patch looks similar to https://github.com/mozilla/fxc2/pull/3/files . I have confirmed that my program can accept -Vn as strictly optional (a default is used if none provided) and added the appropriate test in my CMakeLists.txt file. I did my own wchar_t adjustments to the source-code without seeing the patched you listed. I also did https://code.videolan.org/videolan/vlc/-/blob/master/contrib/src/fxc2/0004-Revert-Fix-narrowing-conversion-from-int-to-BYTE.patch without seeing that patch. I can also confirm that my program accepts MS-DOS style parameters.
I did not know of those patches you listed.
The VLC group's work does not have as many options as I am aiming to provide. Those opetions can become very import when porting some of Microsoft's Open Source DirectX libraries for DirectX11.
DirectXTK requires special documented parameters to compile shaders but unfortunately, fxc2 does not handle those special parameters. at all The efxc2 program handles those parameters by translating them into an appropriate value using a chart at: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/d3dcompile-constants that is then passed to an appropriate API call (https://learn.microsoft.com/en-us/windows/win32/api/d3dcompiler/nf-d3dcompiler-d3dcompile2). I have had success compiling DirectXTK using the efxc2 program.
DirectXTex has optional DirectX11 support that requires a similar thing. I am hoping to enable that in the DirectXTex package.
It is also worth to mention that the "Fo" parameter which is used by Qt 6's qsb tool is not supported by fxc2 but seems to be supported by efxc2 (Although Qt needs to be patched anyway to make use of fxc2 through Wine).
