class BaseA {
	public:
		virtual void foo(){cout<<"Base";};
};

class A: public BaseA {
	public:
		void foo(){cout<<"Child";};
};

A a;
BaseA & base = a;
base.foo();

Will print “Child”.

“Pair polymorphism” is when you want a specific function implementation to be called based on the run time value of two different instances of a class. For instance in the case of:

class BaseA {
};

class BaseB {
	public:
		virtual void foo (BaseA & a) = 0;
};

class A: public BaseA {
};

class B: public BaseB {
	public:
		void foo (A & a);
};

You would want that somehow “void B::foo (A & a)” will be called. The code I posted does not do this.
There is a way to do this, but it requires for a class to know about the implementation classes. It is not a problem in some cases. However, sometimes you want to have an abstraction layer.
An abstraction layer is a set of classes or interfaces, that have no methods or “don’t know” anything about the classes that implement them. For instance you can have a graphics abstraction layer.
You could implement this layer with DirectX. However, this layer will make it easier to afterwards add an implementation with OpenGL without having to make a lot of changes, even if the game is already completed.

How are we going to have a “pair polymorphism” in this case? One solution is using dynamic casting. You can cast a pointer of a parent class to it’s child class(in case the run time value really points to an instance of that class).
Some code:

class BaseA {
};

class BaseB {
	public:
		virtual void foo (BaseA & a) = 0;
};

class A: public BaseA {
};

class B: public BaseB {
	public:
		void foo (BaseA & a)
		{
			foo2 (dynamic_cast<A &>(a));
		}
		void foo2 (A & a);
};

I was asked by someone how this can be done without dynamic casting, because he doesn’t like dynamic casting. I found a way, but it ain’t pretty, and I honestly can’t find any advantage of using this code instead of just using dynamic casting. But here it is:

class BaseA {
	public:
		virtual void DynamicCast() = 0;
};

class BaseB {
	public:
		virtual void foo (BaseA & base) = 0;
};

class A;

class Caster {
	public:
		A * a;
};

class A: public BaseA {
	public:
		Caster * c;
		void DynamicCast()
		{
			c->a = this;
		}
};

class B: public BaseB {
	public:
		Caster * c;
		void foo (BaseA & base)
		{
			base.DynamicCast();
			foo2 (c->a);
		}
		void foo2 (A & a);
};

These kind of bugs might be difficult to figure for a beginner, and even for someone who is not a beginner it can waste time. Luckily, once you wrap the DirectX ID3DSprite with some abstraction and after you encounter this bug once, you can protect yourself from the same bug in the future.

class A {
    public:
        class Observer {
             protected:
                 int GetPrivate(A & a) {return a.ValueA;};
        };
    private:
        int ValueA;
};

class B: public A::Observer {
    public:
        void Foo (A & a) {
             cout<<GetPrivate(A);
        }
};

Class B cannot access the privates of class A directly, but it inherits a subclass of A that can access the privates of A given as a parameter. Since I have just tried this “pattern” recently, I am not sure what is the direct benefit of this.

I believe a benefit can be in the sense of making a programmer’s life easier. Programming languages play several parts. They provide us powerful functionality, but they also suppose to give us ease of use. You can program anything on assembly, but it would be really difficult to write a big game in assembly.
If you do not expose privates via a getter, you give the programmer one less method to think about when he need to use the class’s instance for something.

Can you think how you would use this “pattern”? Do you think there is no use for it?
Tell me what you think.

class Base {
	public:
		virtual void foo() = 0;
		virtual ~Base(){};
};

class A: public Base {
	public:
		void foo() {...};
};

class B: public Base {
	public:
		void Initialize (Base & d) { this->d = &d; };
		void foo() {...; this->d->foo(); };
	private:
		Base * d;
};

As you can see, class B can use class A’s functionality by pointing to it. But what is it good for? Here is a more concrete example.

class BaseTextKeyboard: virtual public BaseClass {
	public:
		virtual void Enable() = 0;
		virtual void Disable() = 0;
		virtual void ClearText() = 0;
		virtual std::string GetText() = 0;
};

class WindowsKeyboard: public BaseWindowsKeyboard, public BaseTextKeyboard {
	public:
		void Enable();
		void Disable();
		void TranslateMessage (WPARAM wParam, LPARAM lParam);
		void ClearText();
		std::string GetText();
		WindowsKeyboard();
};

class TextKeyboard: public BaseTextKeyboard {
	public:
		void Enable();
		void Disable();
		void Initialize (GetKeyKeyboard & A_Keyboard);
		void ClearText();
		void Handle();
		std::string GetText();
		TextKeyboard();
};

class TextKeyboardFeeder: public BaseTextKeyboard {
	public:
		void Initialize (BaseTextKeyboard & A_Delegate);
		void Enable();
		void Disable();
		void ClearText();
		std::string GetText();
		void Handle();
		TextKeyboardFeeder();
	private:
		bool IsEnable;
		std::string Text;
		BaseTextKeyboard * Delegate;
};

I needed to have text input in TRG’s GUI. A line which you can type text, like in a text field in a web form. At first I thought to use direct input for the job. Since I already had some code for direct input and keyboard. I created a class called TextKeyboard, and I had another class for the text field that used it. I quickly found out that reading keyboard is not trivial. You need to deal with shift being pressed, with keys being held down. All this is already dealt with when you process a window message called WM_CHAR, which makes it pointless to achieve the same functionality using direct input.

Since I already wrote the text field class, I wanted to write the “windows keyboard” in a way I could just send it to the text field class and it would work. I then created a base class(BaseTextKeyboard), or an interface for the TextKeyboard which contained virtual methods and only those that are used with the text field.
I then created a class called WindowsKeyboard which implemented BaseTextKeyboard. However, there was a problem. TextKeyboard was created once for every text field, but WindowsKeyboard could only be created once for all the text fields. Every text field was pointing to the same WindowsKeyboard, which made things not to work properly.

The solution? Have a TextKeyboardFeeder class. This class will both implement the BaseTextKeyboard interface and will point to a WindowsKeyboard class. TextKeyboardFeeder will be created once for every text field, and will have it’s own std:string. Only when the text field is in focus, the corresponding TextKeyboardFeeder will read from the WindowsKeyboard class.
We have another layer of feeders that point to the actual WindowsKeyboard. Each text field has it’s own copy of TextKeyboardFeeder. Each feeder copy has it’s own std:string that contains keyboard input, but all the feeders point to the same WindowsKeyboard and read the text input from it.
By the way, since TextKeyboardFeeder point to BaseTextKeyboard, it could also point to TextKeyboard instead of WindowsKeyboard and it would also work. That is the power of delegates.

Is it clear what I was doing? Do you wish to see more code? More detailed explanation? Please reply and tell me what you think.

GUI Example

Draw4Text (x, y, dy, n)
{
	Text (x, y, "Text "+n+".1");
	Text (x, y+dy, "Text "+n+".2");
	Text (x, y+dy+dy, "Text "+n+".3");
	Text (x, y+dy+dy+dy, "Text "+n+".4");
}

Error1 ()
{
	Draw4Batch (512, 384, 30);
}

Draw4Batch (x, y, dy)
{
	Draw4Text (x, y, dy, 1);
	Draw4Text (x, y+dy+dy+dy+dy, dy, 2);
}

Error2 (a)
{
	Error ("Testing error number 2");
}

The problem? I don’t know what I want to have in TRG’s GUI yet. I believe it’s better to develop code around “real life situations”, rather than guessing what features I will need. My solution is to use the tool as an example of the requirements from the little language. With the tool I will be able to build GUIs, but the tool itself need to have a GUI. I will build the GUI of the tool with a text file, and after I will have the first version of the tool, I will build the next version of the tool’s GUI with the earlier version. Sort of a recursive development. The tool will be used as both an example of what I need and both as the tool to create the next iteration.
It is a sort of a compromise, but I think it’s better than just guessing.

In programming this can mean planning ahead how you are going to solve a problem, or researching for the right existing technology to use.
However, things are not as simple as that. Planning consume thought resources or effort. You might end up planning too much ahead or investing long hours in planning something you don’t really know if it will work. This means there need to be a balance between planning and just trying things out. It might sound funny, but I believe you don’t want to sweat too much most of the time you code. A game requires large amounts of code and work, and if every minute of it would require you a lot of thought and effort, you will quickly burn out. A lot of the time coding should be easy or with very little effort. Of course, sometimes it’s tough. And sometimes it gets really tough, but you want to minimize the times it gets really tough.

The thing that inspired me to write this article is some code I had to write to build a tree from a data structure. This data structure is the result of a text file I parsed with boost::spirit(more about that in future post). In my first attempt I simply used a tool I had available, of building a tree. I forgot I had another tool built upon it that would make my life much easier.
The basic tool would call two virtual methods, build child and build sibling, and with those you are suppose to build the tree. The code I wrote for this tool was long, ugly and didn’t work. After this failed attempt I realized I have a tool I built upon the basic tool. This tool allows me to add the edges of the tree. I have an AddEdge method that gets parent index, child index and node data. The implementation make sure all those edges I add will create a tree after I call BuildTree. A lot simpler.
The first code snippet is of the advanced tree building tool, and the second code snippet is of the basic building tool. Notice the code is not spartanized much, and you don’t really need to try and understand it. Just try to see which one looks prettier. You might not see the code if you are not at the original blog website(because it’s a lot of code, and because of different plug-ins), so for the code you should visit my blog.

	void
	NodeFunction::NodeFunctionCall::AddNode (MathNode n, DWORD A_Parent, DWORD A_ListIndex, Tree::Builder & b)
	{
		using boost::fusion::at_c;
		this->CurrentIndex++;
		DWORD i = this->CurrentIndex;
		if (at_c<1>(n.Node).size()!=0)
		{
			NodeFunction::NodeFunctionCall::ParameterNode NodeData;

			NodeData.IsOperation = true;
			NodeData.Operation = at_c<0>((at_c<1>(n.Node))[A_ListIndex]);
			b.AddEdge (A_Parent, i, NodeData);
			if (A_ListIndex==0)
				this->AddSingleNode (at_c<0>(n.Node).get(), i, b);
			else
				this->AddSingleNode (at_c<1>((at_c<1>(n.Node))[A_ListIndex-1]).get(), i, b);
			if (A_ListIndex+1==at_c<1>(n.Node).size())
				this->AddSingleNode (at_c<1>((at_c<1>(n.Node))[A_ListIndex]).get(), i, b);
			else
				this->AddNode (n, A_Parent, A_ListIndex+1, b);
			return;
		}
		this->AddSingleNode (at_c<0>(n.Node).get(), A_Parent, b);
	}

Basic tree builder code.

	MemberClass >
	NodeFunction::NodeFunctionCall::Builder::CreateNode (MathNode A_Node, MathNode A_ExtraNode, DWORD A_Index, bool A_ExtraSibling)
	{
		MemberClass > Result;

		NodeFunction::NodeFunctionCall::ParameterNode NodeData;

		Result->bCreate = false;
		bool IsExtraSibling = false;

		if (A_Index!=0 && A_ExtraSibling && (A_Index-1)==boost::fusion::at_c<1>(A_Node.Node).size())
		{
			IsExtraSibling = true;
			A_Index = 0;
			A_Node = A_ExtraNode;
			A_ExtraSibling = false;
		}

		while (boost::fusion::at_c<1>(A_Node.Node).size()==0)
		{
			MathSingleNodeType * SingleNode = &(boost::fusion::at_c<0>(A_Node.Node).get().Node);
			boost::recursive_wrapper * p = boost::get >(SingleNode);
			if (p==NULL)
			{
				Result = this->CreateSingleNode (boost::fusion::at_c<0>(A_Node.Node).get());
				if (IsExtraSibling)
					Result->Data.IsSibling = false;
				return Result;
			}
			A_Node = p->get();
		};

		if (A_Index(A_Node.Node).size())
		{
			ComplexNode c = boost::fusion::at_c<1>(A_Node.Node);
			NodeData.IsOperation = true;
			NodeData.Operation = boost::fusion::at_c<0>(c[A_Index]);
			NodeFunction::NodeFunctionCall::BuilderData b;
			b.IsSibling = true;//!IsLast || A_ExtraSibling;
			boost::recursive_wrapper * Single = A_Index==0?&boost::fusion::at_c<0>(A_Node.Node):&boost::fusion::at_c<1>(c[A_Index-1]);
			MathSingleNode n = Single->get();
			if (boost::get >(&n.Node)!=NULL)
				b.Node = boost::get >(n.Node).get();
			else
			{
				MathNode m;
				boost::fusion::at_c<0>(m.Node) = *Single;
				b.Node = m;
				if (A_Index==0 && !IsExtraSibling)
					b.IsSibling = false;
			}
			bool IsLast = A_Index==boost::fusion::at_c<1>(A_Node.Node).size()-1;
			b.IsNull = false;
			b.Index = A_Index;
			if (IsLast)
			{
				b.IsExtra = true;
   				boost::recursive_wrapper * Single = &boost::fusion::at_c<1>(c[A_Index]);
				n = Single->get();
				if (boost::get >(&n.Node)!=NULL)
					b.ExtraNode = boost::get >(n.Node).get();
				else
				{
					MathNode m;
					boost::fusion::at_c<0>(m.Node) = *Single;
					b.ExtraNode = m;
				}
			}
			Result->bCreate = true;
			Result->NodeData = NodeData;
			Result->Data = b;
			return Result;
		}
		GlobalErrorWrap::Assert (false, "Unreachable ParsedGUI build code");
		return Result;
	}


class BaseSpriteDrawer {
public:
    void DrawCenter (int x, int y, Texture & t)
    {
     this->Draw (x-t.GetWidth()/2, y-t.GetHeight()/2, t);
    };
    virtual void Draw (int x, int y, Texture & t) = 0;
}

class SpriteDrawerA: public BaseSpriteDraw {            
public:
    void Draw (int x, int y, Texture & t);
};

class SpriteDrawerB: public BaseSpriteDraw {            
public:
    void Draw (int x, int y, Texture & t);
};

In this example you can see there are two different implementations for drawing sprites. Each one of those have different code for Draw. However, DrawCenter has the same code for both implementations so instead of writing the same code twice for each of the implementations, I have used inheritance. We have “copy pasted” the content of the class BaseSpriteDrawer or “copy pasted” DrawCenter.
The reason copy pasting is bad, is that you have the same code to maintain in two different places. If you discover a bug inside a function, you need to fix all the places you copy pasted that function. You just have more code to maintain, more copies of the same thing to maintain which translates into more work and more bugs.
There is also the additional bonus of saving you a lot of time. Sometimes you need the same code with small variations, and it would seem more work to figure out how to do this with inheritance, instead of just copy pasting and having two copies of the same code. However, in case you need a third copy of the code, with the inherited code it would be a lot easier to create the third “copy” of the code instead of copy pasting the same code for the second time.

If you are a beginner, I suggest you try to avoid copy pasting almost completely. It would be a good exercise or a good challenge to try doing something else each time you have the urge to copy paste some code. That being said, I myself don’t completely avoid copy pasting. While as a rule of thumb, its better to avoid copy pasting, sometimes its the fastest immediate solution. The thing is, not all of my code get the same treatment. Some code get better treatment than other code. If its code that is not so important and is not long, then I might copy paste it. I also might copy paste something, and when I see I get back to the same code to add something new, I would fix my bad practice of copy pasting and make a better, cleaner code.

There is a lot more to talk about this subject, and a lot more examples and techniques of how to avoid copy pasting. Copy pasting is actually implied from spartan programming, I have already mentioned spartan programming  and I hope to talk about it in future posts.

ostringstream OStr;
OStr<<"Not 1 or 2("<<i<<")";
Error::Assert (i==1 || i==2, OStr.str());

With this code the walls drawing function took 7% of a specific time. Then I changed this part of code to:

ostringstream OStr;
OStr<<"Not 1 or 2";
Error::Assert (i==1 || i==2, OStr.str());

After this change I got 4%. I then changed it to:

Error::Assert (i==1 || i==2, "Not 1 or 2");

And I got down to 2%. The conclusion is that performance can be very tricky. What might seem innocent(A simple string handling) might turn to be big CPU usage when performed inside a loop.
I found that there is quite an imagination between profiling and debugging. Maybe there is a way to reduce the time of profiling and avoid from these kind of pitfalls? I hope to figure this out in the future. I think there is something that might help.

I would say its a good habit to do some thinking after solving a bug, and not immediately move on to the next task. Why this bug happened? How I solved it? Did I really solve it? How can I prevent similar bugs from happening in the future? Should I prevent similar bugs in the future or is it not cost effective and having this kind of bug from time to time is acceptable?

Last but not least, you need to take what I said with a grain of salt. This is something that worked for me, from my own experience under certain conditions, but you don’t have to do exactly the same. Its not formal anyway, because you can’t 100% formalize programming. Its an advice, not rules or a recipe to follow blindly.

Pre Requirements
In order to implement this algorithm, one need to have a geometry based or fins geometry Non Photo Realistic outline shaders implemented. 
This type of shader use a mesh of fins. For every edge or intersection between two triangles in the original mesh, there is a fin in the fins mesh. When rendering this fins mesh, we select in the shader which fins will be visible and which will not. The fins that are visible are those that one of the two triangles the fin belongs to is facing the camera and the other doesn’t. This cause that the viewable fins are the outline fins of the projected mesh on the screen space.
Some articles explaining how to do this, can be found here:
Single Pass GPU Stylized Edges
NPR with Pixel and Vertex Shader

How it works
Once you have the fins geometry, either by precalculating or using the geometry shader, you need to add additional information to the vertexes of the fin. If you are drawing a black fading outline using the fin geometry, you already have a V coordinate that is 0 where the fin is touching the 3D model and 1 at the farest point of the fin from the 3D model. For the faded black outline, we use this V coordinate to determine what alpha value we want the fin to have in the pixel.

The additional information we need to add, is all the information we have in the 3D model vertex where the fin come out from, which is used to calculate the final color of the correspondent triangles. For instance, if the vertex keeps a normal to calculate diffuse lighting, we need to keep this normal in the correspondent fin vertex as well.
We pass this information from the fin vertex to the pixel shader and on the pixel shader we calculate the color just like we would calculate the color in the pixel shader of the 3D model.
The next step is to multiply the fin color with an alpha, much like we did with the faded black alpha, and we get the anti aliased edge.
The results are shown in the following images of a ball and a scene from the game Labyrinthica: The quest of lima. For comparison I have included a render with no AA and a render with AA from an NVIDIA Geforce 8600 GTS set at 16Q.
Also a render of GAA outline without the 3D model.

Aliased ball

Built in Anti Alias

GAA ball

GAA only

Performance, quality and issues
GAA might prove to have better or worse performance than the built in AA of the graphics card.
The main bottlenecks of GAA are the vertex shader, in case no geometry shader is available, and part of the bottlenecks that the 3D model suffer from depending on the shader it use to calculate color. For instance, a use of texture might cause a memory bus bottleneck. On the other hand, GAA will most likely be calculated for only small part of the pixels on the screen, unlike the graphics card AA which is calculated for all the pixels in the screen.
In terms of quality, GAA has several differences from built in AA. You can control the fin’s thickness, making it possible for smoother and more pleasing AA. It does not make textures or models’ surfaces blurred or smoothed. And you can add a black outline for NPR rendering almost for free.

GAA might not work for edges with very high curvature or surface with unsmooth normals or unsmooth parameters used for calculating the color. Problems may arise due to the fact that the color on a specific vertex of a mesh is not the same color as the pixel next to it. Because the data at the pixel is the interpolation of 3 vertexes and not the exact data in the closest vertex. This might cause problems such as back facing normals on the fin.