why do they put shader code in .cpp file
Author
I saw serveral projets that put shader code in the .cpp file instead of .fx or other shader file.
I wonder if this way can improve anything.
-----------------------------------------------------------------------
In one project, the shader can verify according to the configuration:e.g.
if (lightOn)
"..."
else
"..."
well this is the only advantage I can see;
-----------------------------------------------------------------------
on the other hand, this action slow down the loading process;
make the code tousy.
I will not choose to put shader code in .cpp file.
is there any advantage of putting shader in .cpp file.
One thing to remember is that there is absolutely no difference between file extensions. None. Well, except for the default program to open them in. They all just come down to bits in the end, it doesn't matter whether you call those bits image.bmp, or highscores.txt, or shader.fx, or shader.cpp, they are still the same bits. The only difference being that highscores.txt will be opened by Notepad by default, image.bmp opened by Paint, and shader.fx/.cpp won't be opened by anything by default.
I think the question is not so much about the extension being .fx or .cpp, but about actually putting shader code into a source file.
This *does* make a noticeable difference.
There are at least 2 reasons I could imagine why one would want to do that:
1. to hide the shader (being unaware that it is still very easy)
2. to generate a dynamic shader optimised for the hardware present on a system, or for user preferences
Number 1 does not take into account that it is still trivial to get to the shader code out of the executable with a hex editor. Even if you encrypt your shader, GlIntercept or similar tools will be trivially able to catch it. At some point, the shader must exist in plain text, or it cannot be compiled by the driver and sent to the graphics card.
Number 2 works, but it is a lot more efficient to define shader constants, and write a shader that #ifdefs ceratain pieces of code based on those constants.
That way, all you need to do is change those constants, which is just as fast as uploading another shader in the worst case, but significantly faster in the likely case (depends on the individual implementation).
In any case, using constants is a lot less error-prone, easier during development, and it uses no CPU cycles for concatenating alternative strings.
This *does* make a noticeable difference.
There are at least 2 reasons I could imagine why one would want to do that:
1. to hide the shader (being unaware that it is still very easy)
2. to generate a dynamic shader optimised for the hardware present on a system, or for user preferences
Number 1 does not take into account that it is still trivial to get to the shader code out of the executable with a hex editor. Even if you encrypt your shader, GlIntercept or similar tools will be trivially able to catch it. At some point, the shader must exist in plain text, or it cannot be compiled by the driver and sent to the graphics card.
Number 2 works, but it is a lot more efficient to define shader constants, and write a shader that #ifdefs ceratain pieces of code based on those constants.
That way, all you need to do is change those constants, which is just as fast as uploading another shader in the worst case, but significantly faster in the likely case (depends on the individual implementation).
In any case, using constants is a lot less error-prone, easier during development, and it uses no CPU cycles for concatenating alternative strings.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
