In previous parts of this series, we briefly discussed the need for Shaders and created our first Shader Program. In this subsequent part, we would be exploring on passing additional parameters to our Custom Shader.

In previous example, we replaced entire color of applied Control with a single color. What if we need to replace only certain colors, among different colors in the control. We would then need to pass the ‘color to replace’ and ‘new color’ to the Shader.

Let’s write our Shader, again with HLSL. We will delve into details soon.

```sampler2D input: register(s0);
float4 oldColor : register(c0);
float4 newColor : register(c1);

float4 main(float2 uv:TEXCOORD) : COLOR
{
float4 color = tex2D(input, uv);
if (color.r == oldColor.r && color.b == oldColor.b && color.g == oldColor.g)
{
return newColor;
}
return color;
}
```

We now have two additional parameters defined in the Line 2 & 3. While it follows the earlier parameter declaration, there is an important difference. For additional (non-image) parameters, we are using the C series registers, which are, as discussed in last post, floating point registers. We have two parameters, both of type float4, which would hold details of ‘old color‘ and ‘new color‘.

```float4 oldColor : register(c0);
float4 newColor : register(c1);
```

In the first line of our main function, we see a new function, which we haven’t seen in previous example.

```float4 color = tex2D(input, uv);
```

tex2D is a texture sampling intrinsic function, which generates a vector from its a sampler and a float2, which holds the two-dimensional texture cordinates at which the sampler is to be sampled. The cordinates (u and v), ranges from (0,0) to (1,1) as one moves from top-left to bottom-right.

In the subsequent code, which is self-explanatory, we compare the RGB values to decide whether we need to replace the color.

Step 02 : The ShaderEffect Class

Having written our Shader, the next obvious step is create our custom class derieved from ShaderEffect. Like in Shader code, we will write the code first and then explore the details.

```public class ReplaceColorEffect : ShaderEffect
{
public Brush Input
{

get => ((Brush)(GetValue(InputProperty)));
set => SetValue(InputProperty, value);
}

public Color OldColor
{
get { return (Color)GetValue(OldColorProperty); }
set { SetValue(OldColorProperty, value); }
}

public static readonly DependencyProperty OldColorProperty =
public Color NewColor
{
get { return (Color)GetValue(NewColorProperty); }
set { SetValue(NewColorProperty, value); }
}

public static readonly DependencyProperty NewColorProperty =

public ReplaceColorEffect()
{

}
}
```

While most of the code is pretty similiar to code in our previous example, ones that needs more attension is discussed below. The most significant difference is the two additional parameters, which are mapped to floating point registers (c registers) and how it is defined in C# code.

```public Color OldColor
{
get { return (Color)GetValue(OldColorProperty); }
set { SetValue(OldColorProperty, value); }
}

public static readonly DependencyProperty OldColorProperty =
```

As observed in the code above, the declaration of dependency properties for c-registers are in the more familiar & conventional syntax, using the DependencyProperty class. What makes it different from normal dependency properties is the PixelShaderConstantCallback parameter of PropertyMetadata class. This tells the compiler that this is a special Dependency property which needs to be mapped to c-registers when communicating with the Shader application.

Rest of the code is pretty self-explanatory and XAML is no different than ones you might have seen countless times, using the dependency properties.

```<shadereffects:ReplaceColorEffect OldColor="Red" NewColor="Green"/>
```

Hit F5 and you can now see your Shader in action. For complete code discussed in this series, please refer to my Github.

# Assignment using Ternary Operator

Couple of days back, I happened to come across a question in StackOverflow. Question seemed pretty straightforward, but at the same time, interesting. How would one use ternary operator for assignment. For example, how would write following code using ternary operator.

```var a = 1;
var b = 2;
var c = 3;
var flag = false;
if(flag)
a = c;
else
b = c;
```

Obviously, following wouldn’t work.

```// CS0131 The left-hand side of an assignment must be a variable, property or indexer
(flag?a:b) = c;
```

One way to use ternary operator would using Action.

```(flag ? new Action(() => a = c): () => b = c)();
```

But that doesn’t quite give you the clean syntax of Ternary Operator. That brings us to the second way using features exposed by C# 7.2. Let us rewrite the code.

```(flag ? ref a : ref b) = c;
```

Enjoy coding…

# C# 8.0 : Default Implementation of Interface Members

The way C# language is evolving is definitely exciting and one feature that truly makes the wait for C# 8.0 all the more exciting is default implementation of interfaces.

Since the onset, interfaces were behaviors characterized by member signatures, strictly disallowing any implementation. All that is going to change when C# 8.0 rolls out, as it supposedly, plans to support default implementation of interfaces. What it means is further trimming down the walls between interface and class (but remember, walls would still exist : Interface and Classes will still have significant difference, we will talk about it a bit later.)

Let’s look at an example, courtesy MSDN Blogs.

```interface ILogger
{
void Log(LogLevel level, string message);
void Log(Exception ex) => Log(LogLevel.Error, ex.ToString()); // New overload
}

class ConsoleLogger : ILogger
{
public void Log(LogLevel level, string message) { ... }
// Log(Exception) gets default implementation
}
```

Doesn’t that look exciting ? Gone are days when as an Author of an interface, you were almost handicapped extending the interface fearing it might break any of implementing code. You could now provide the default implementation of your interface member, and still be assured that all implementing code works as fine as it was before.

If this doesn’t excite you, think from another perspective. What this implies is possibility of multiple inheritance (almost) in a language that was never really supported it. You could now provide two interfaces with default implementation, and have a class inherit from both.

```interface IParentA
{
string MethodA() => nameof(MethodA);
}

interface IParentB
{
string MethodB() => nameof(MethodB);
}

class Child : IParentA,IParentB
{
void MethodChild()
{
Console.WriteLine(\$"{nameof(MethodA)} = {MethodA()}");
Console.WriteLine(\$"{nameof(MethodB)} = {MethodB()}");
}
}
```

This effectively brings in Multiple Inheritance in place. What would be interesting to see is how Microsoft circumvented the Diamond Problem. Let’s delve a bit into Diamond Problem first, before trying to understand Microsoft’s workaround from what ever we know as of now.

Diamond Problem

Let’s consider the following inheritance structure assuming C# were to support Multiple Inheritance.

```class A
{
public virtual string DemoMethod() => \$"{nameof(A)}.{nameof(A.DemoMethod)}()";
}

class B : A
{
public override string DemoMethod() => \$"{nameof(B)}.{nameof(B.DemoMethod)}()";
}

class C : A
{
public override string DemoMethod() => \$"{nameof(C)}.{nameof(C.DemoMethod)}()";
}

// Let's assume this works for sake of demonstration
class D:B,C
{
public void Print()=> Console.WriteLine(DemoMethod());
}
```

In the above code, class D inherits from both Class B and Class C, both of which, in-turns inherits from Class A and overrides virtual member DemoMethod. Assuming this code compiles, what would be the output of Print() Method in Class D. Will it invoke method from Class B or Class C ? This ambiguity is better known as Diamond Problem.

Microsoft intents to work around the Diamond Problem here by taking the most specific override at the time. As Microsoft pens it down

“Diamonds with Classes

A class implementation of an interface member should always win over a default implementation in an interface, even if it is inherited from a base class. Default implementations are always a fallback only for when the class does not have any implementation of that member at all.”

Let’s rewrite the above code using default implementation of interfaces.

```interface A
{
string DemoMethod() => \$"{nameof(A)}.{nameof(A.DemoMethod)}()";
}

interface B: A
{
override string DemoMethod() => \$"{nameof(B)}.{nameof(B.DemoMethod)}()";
}

interface C: A
{
override string DemoMethod() => \$"{nameof(C)}.{nameof(C.DemoMethod)}()";
}

// This would be Error as no most specific override for A.DemoMethod()
class D:B,C
{
public void Print()=> Console.WriteLine(DemoMethod());
}

// This would be Error as no most specific override for A.DemoMethod()
class E:B,C,A
{
string DemoMethod()=> B.base.DemoMethod();
public void Print()=> Console.WriteLine(DemoMethod());
}
```

So will now abstract class == interface ?

No, not really. Even though the differences are diminishing, there still lies a lot of difference between the two. To name a few
– Unlike Abstract Class ,you still can’t write a default constructor for interface.
– Covariance and Contravariance

Essentially, abstract class and interface would continue to coexist in its own space. What Microsoft has done with Default Implementation of Interface is making use of Traits (more on traits later.)

In the first part of series, we wrote our first Shader Program. Now it is time to compile it so that we could use it in our WPF Application.

HLSL Compiler

To compile your HLSL code to a format that could be used with .Net WPF application, you would require the fxc compiler. For Windows 7 and earlier editions, you would need to install DirectX SDK in order to get fxc.exe. For Windows 8 and above, this comes as part of the Windows SDK.

The compiler can found under the location ‘Program Files (x86)\Windows Kits‘. If we had saved our previous written code (from previous part of this series) as RedTint.hlsl, we would need to use following command to compile it.

```fxc /T ps_2_0 /E main /Fo RedTint.ps RedTint.hlsl
```

This would give the necessary ps file, or Pixel Shader file which we could now refer in our WPF Application. Now that we have our Pixel Shader file, we will move on to our WPF application.

Creating our Test Application

We will keep our text application simple. The XAML code is shown below.

```<Grid Margin="10,10,10,10">
<Grid.RowDefinitions>
<RowDefinition Height="*"/>
<RowDefinition Height="4*"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<Label Grid.Column="0" Grid.Row="0" Content="Normal Button" HorizontalAlignment="Center"/>
<Button Grid.Column="0" Grid.Row="1" Content="Click Me"/>

<Label Grid.Column="1" Grid.Row="0" Content="Button with Shader" HorizontalAlignment="Center"/>
<Button Grid.Column="1" Grid.Row="1" Content="Click Me"/>
</Grid>
```

Also enclosed is a screenshot of the application. The purpose of our application would be apply our shader to one of the buttons, while leaving the other button untouched, so that we could easily demonstrate the difference (or rather impact of shader). We will also add our RentTint.ps file to our project as a resource.

Defining Custom Effect

To use the compiled shader application, we need to load it to the rendering engine input stream. This is accomplished with the help of ShaderEffect class in .Net. The ShaderEffect base class makes it possible to wrap the HLSL pixel shader and apply them our applications XAML elements.

```public class RedTintEffect: ShaderEffect
{
public Brush Input
{

get => ((Brush)(GetValue(InputProperty)));
set => SetValue(InputProperty, value);
}

public RedTintEffect()
{

}
}
```

We have defined our custom effect, namely RedTintEffect, derieved from ShaderEffect. Let’s examine the code closely beginging with the constructor.

```public RedTintEffect()
{

}
```

The first step we need to is to initialize an object of PixelShader (which is a protected member of ShaderEffect class) and refer our ps file using the UriSource property. This would enable the ShaderEffect to communicate with the GPU.

The next step is to create a Dependency Property of Type Brush, calling it “Input”. This is a special property and would contain the input image. There lies a difference in the way we register the Dependency Property as well. Instead of the usual DependencyProperty.Register(), we would be using ShaderEffect.RegisterPixelShaderSamplerProperty() method.

```public static readonly DependencyProperty InputProperty = ShaderEffect.RegisterPixelShaderSamplerProperty("Input", typeof(RedTintEffect), 0);
public Brush Input
{

get => ((Brush)(GetValue(InputProperty)));
set => SetValue(InputProperty, value);
}
```

One of the important points to note in the above code is the final parameter of ShaderEffect.RegisterPixelShaderSamplerProperty() method. The Integer value 0 corresponds to the S0 pixel shader register in our HLSL code. Here is the refered code from HLSL source.

```sampler2D input: register(s0);
```

That’s all we need. We can now go back to our XAML and apply the effect.

The update code is as follows.

```<Grid Margin="10,10,10,10">
<Grid.RowDefinitions>
<RowDefinition Height="*"/>
<RowDefinition Height="4*"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<Label Grid.Column="0" Grid.Row="0" Content="Normal Button" HorizontalAlignment="Center"/>
<Button Grid.Column="0" Grid.Row="1" Content="Click Me"/>

<Label Grid.Column="1" Grid.Row="0" Content="Button with Shader" HorizontalAlignment="Center"/>
<Button Grid.Column="1" Grid.Row="1" Content="Click Me">
<Button.Effect>
</Button.Effect>
</Button>
</Grid>
```

We have added our newly added custom Effect to one of the button. Let’s hit F5 and verify our changes.

As observed in the screenshot, the Button to which the Effect was applied has turned Red, while the other Controls remain the same. Do observe that even the Forecolor of Text within the button has turned Red. This is true to our definition of our Shader, since it returns Red irrespective of the input. We will look into more complex scenarios in later posts where we will introduce conditional color changes.

You can access the entire source code described in Part 1 and Part 2 of this series from my Github

# Shaders with HLSL #01 : Shaders with HLSL for WPF Developers

Complete Tutorial Series

In this first part of our tutorial, we will briefly enlighten ourselves on key concepts involving shaders and why it is required. We will also write our first shader application, introducing ourself to the HLSL semantics.

Shaders are small programs written to run on the GPU (Graphical Processing Unit) and describes how to render each pixel. Since running parallely on the GPU hardware, they typically produces faster output,compared to having it run on the CPU.
There are mainly two types of Shaders

• Vertex Shader – Vertex Shader gets the first chance to work on Model, prior to even Rasterizer and is responsible for transforming vertex.
• Pixel Shader – Pixel Shader comes into pipeline a little later, after Rasterizer and is responsible for determining the final color of a pixel

The huge computing power of modern GPUs ensures complex and graphically rich applications have little impact on performance. Begining with .Net 3.5 SP1, Microsoft introduced hardware accelerated affects for WPF (Effects in WPF, for example Blur Effect and DropShadowEffect) utilizing the power of shaders. We could write our own custom shaders and use them in our WPF applications.

Evolution of HLSL/C

One of the earliest approaches for writing Shaders used assembly language, but soon it was evident that the inherient complexity of Assembly Language was not making it any easier. This lead to development of Cg (C for Graphics) by NVida and HLSL (High Level Shader Language) by Microsoft. Both languages follows a similiar syntax and is closely associated to C Language in syntax and compile shaders for DirectX.

Getting Started with HLSL

Let’s write some code first and then we will go in detail examining the code as well as how to use it in your WPF Application.

```sampler2D input: register(s0);

float4 main(float2 uv:TEXCOORD) : COLOR
{
return float4(1.0f, 0.0f, 0.0f, 1.0f);
}
```

The first line of code represent our input parameters, stored in GPU registers.

```sampler2D input: register(s0);
```

Pixel Shaders rely on GPU registers input, which are high speed storage areas. There are different types of registers, but most of our applications written in C# depends on S and C register1 types. The S registers, also known as Sampler Registers are mainly used for storing input images data2. If we need to pass another Image Source, we could pass it via the register s1. We could pass other arguements to our shaders using the C registers (floating point registers), but for the sake of our first example, we will keep it simple with just a single input parameter, which is our Image data.

The first line of code specifies an input variable input and the register to use for the purpose. It also specifies the input type, which in this case is sampler2D and refers to the image it is being applied to.

The main as one can easily guess, represent the entry point of the shader code. The incoming parameter uv represents the incoming texture cordinates, while the return type float4 represents an RGBA color.

```float4 main(float2 uv:TEXCOORD) : COLOR
```

The body of our first Shader application is pretty simple, it returns a color representing Red.

```return float4(1.0f, 0.0f, 0.0f, 1.0f);
```

Let’s save the above code with extension “hlsl”. In the next part of tutorial we will examine how to compile our HLSL code to ps format, which would be later consumed by our WPF application.

1. More on Registers : Source : Microsoft
2. Image, in this context refers to visual representation of the target control.

# Early Exceptions for Iterator and async Methods

One of the first things you would need to be vary of while working with Iterator methods and async methods is exception handling. Both Iterator methods and async methods delay the execution of your code, right until you need the result, but it also results in delayed exceptions.

Late Exception With Iterator Methods

Let’s consider a typical example. The following method generates positive integers from 1 to ‘n’. Of course, you could do this with Enumerable.Range but, that’s not the whole point.

```void Main()
{
var maxValue = 0;
var generatedCollection = GenerateSequence(maxValue);
Console.WriteLine("No Exception raised yet");
foreach(var item in generatedCollection)
Console.WriteLine(item);
}

IEnumerable<int> GenerateSequence(int maxValue)
{
if(lastNumber <= 0)
throw new Exception(\$"Parameter {nameof(maxValue)} should be positive, non-zero");

for(int i=0;i<maxValue;i++)
yield return i;
}

```

The above method has a precondition which validates if the maxValue parameter is a positive, non-zero number. However if one was to execute the code, one can notice that exception isn’t raised until the result is consumed. This is expected. But, there could be scenarios where one might require you to have methods raise early exceptions.

Early Exception With Iterator Methods

Let’s rewrite the method with a little bit of tweak1.

```void Main()
{
var maxValue = 0;
var generatedCollection = GenerateSequence(maxValue);
Console.WriteLine("No Exception raised yet");
foreach(var item in generatedCollection)
Console.WriteLine(item);
}

IEnumerable<int> GenerateSequence(int lastNumber)
{
if(lastNumber <= 0)
throw new Exception(\$"Parameter {nameof(lastNumber)} should be positive, non-zero");

return Generate();
IEnumerable<int> Generate()
{
for(int i=0;i<lastNumber;i++)
yield return i;
}
}
```

Try executing the code, and you can notice that now it supports early exception. This very approach could be used for async method. Let’s do the problematic code first.

Late Exception with async Methods

```async Task<int> Increment(int numberToPrint)
{
if(numberToPrint <= 0)
throw new Exception(\$"Parameter {nameof(numberToPrint)} should be positive, non-zero");

}

// Client code
var value = 0;
Console.WriteLine("No Exception raised yet");
```

The problem with late exceptions is visible in the above code as well. The exception is not raised where the method is called (in code), but rather it is raised when the Task is awaited.

Early Exception with async Methods

```Task<int> Increment(int numberToPrint)
{
if(numberToPrint <= 0)
throw new Exception(\$"Parameter {nameof(numberToPrint)} should be positive, non-zero");

return Increment();
{
}
}

// Client Code
var value = 0;