Anyway, I think what youâre doing might be the easiest solution. Personally though, I donât like to put those in my code because theyâre a real pain to track down sometimes! I think the only thing I might be able to offer is some kind of dependency injection solution where you give it an object that has different behaviour depending on whether or not youâre in debug mode.
Looking at what you have, perhaps an interface called IEffectParameterSetter or something like that so at least itâs reusable for other, similar situations. Then you can have two implementations, one with the if statement (DebugEffectParameterSetter) and the other without (EffectParameterSetter). Probably some kind of factory for creating the appropriate ones and in your programâs entry point, pass the appropriate dependency down or stuff it in a dependency container of some sort and retrieve it where needed.
I mean, itâs kind of like the more testable, maintainable version of a macro anyway⌠except it also takes a good bit more effort to create
Macros (and static variables inside functions) are the only things I miss from my old C++ times. I understand perfectly that macros are not included into the language, when misused they can bring complete chaos to a project.
Lately Iâve found that local functions are a very nice way to do some stuff I used the macros for. Theyâre not in any way a substitution for macros, but they help me a lot.
Using the ? there will do a null check before continuing. It only does one index lookup instead of the two it does in your code. I would consider this the correct way to do it, the single null check will realistically never impact performance (youâre not setting thousands of parameters per frame) and it gives you the ability to easily modify your shader. You probably wouldnât want to disable shader optimizations anyway.
One option is to write a âpre-processorâ or âmeta programâ that modifies your code before it is compiled (basically just do a find / replace). I think handmade hero shows how you would it in C++ episode 206 if you want an example.
I believe the correct way to do this is using functions with the Conditional attribute.
I think an additional pragma inside the function will also reduce the compiled size for Release builds, while not breaking the function call that will ultimately be ignored.
[Conditional("DEBUG")]
public static void AssertTrue(bool b)
{
#if DEBUG
if (!b)
{
throw new Exception();
}
#endif
}