Loading the Shader

December 17 2022

The code to load the shader needs to be cleaned up, at least to remove that ugly hard-coded file name.

The shader is fed to ID2D1EffectContext::LoadPixelShader() as a blob of bytes, which is the contents of the shader.cso file output by the HLSL compiler. All I need to do is figure out a better way to load the cso file.

There are several methods that will work, there is no real difference in runtime performance. The most important factor is which method fits into the build process with the fewest headaches, is the easiest to maintain, and least confusing.

External File

I just need to make sure the shader.cso file ends up in the app's working directory, $(SolutionDir)Test. This means adding a post-build batch file to copy the cso file from $(OutDir) to $(SolutionDir)Test.

Upside: The cso output file can be used as-is without any modifications, the code is to load remains the same, and the batch file can perform other functions as well. The shader file can be updated or swapped without recompiling the project.

Downside: It requires a custom build step. Shader.cso needs to always be deployed along with PxlShader.exe.

Embedded Bytes

The hlsl compiler has an option to output the binary code as C code to shader.h, which is then included into the project and compiled into an internal BYTE Shader[] array that can be passed directly to LoadPixelShader().

Upside: This makes the loading code brain-dead simple.

Downside: This makes a mess of the build rules. PxlShader.cpp depends on shader.h, which is an output of FirstPxlShader.hlsl. The project needs to be configured so that shader.h is recognized as an output file, and then anyone who works on the project needs to also know this. Anything that smells this funky should be avoided.

Embedded Resource

Include the shader.cso output as an imported binary resource, specified in the PxlShader.rc file. Then load the resource into memory and feed that to LoadPixelShader().

Upside: Shader.cso is embedded in the PxlShader.exe file, so it can never be lost. The build system understands how to include output files into the resource script, so no special build rules are required.

Downside: Adding the Shader.cso to the resources can be a bit tricky, but this is a one-time thing. Since the shader is embedded in the exe file it cannot be swapped out. The loader code is more complicated as it now has to load a resource, adding another three or four lines of code.

Loading an External File

The external file approach feels the best, especially as this is an experimental project where being able to swap out different versions of the shader is likely to be very handy.

All I need to do for this is add a batch file that will be run as a post-build step.

Create a new Build folder and add Deploy.bat as a Utility/Text item:

Add a post-build step:

Command line: $(ProjectDir)Deploy.bat "$(SolutionDir)Test" "$(OutDir)"

And now I can load the shader from the current directory, removing the hard-coded path: