I just wanted to say that I am not sure how often I will update my blog. I have started to work on a new job which I enjoy a lot.
I am going to keep a low profile on game development. I believe I will be back to it sooner or later.

Thank you for reading.

What do you think?

An example. Say you have written code to load a BMP file format. You use your program, but the image has some weird artifacts. Is it a bug in your code? Or is it a corrupted BMP file?
You can simply load the same BMP file with another program such as window’s paint, and see if it loads properly or if paint is having problems with this file as well. If paint loads the BMP file properly, the bug might be in your code.

I have given the BMP file format as an example, but this is true to many other fields where you have some tool you know is working right. It is kind of similar to the Bug negative verification.

I think it’s a common trait of humans to try rationalize everything. Sometimes they are so convinced at something and the logic behind it, even though it has no basis or it is even something that can’t make sense.

Does it happen to you too?

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.

It is also relevant to game development. Especially in terms of efficiency. You might procrastinate doing things because you need to finish some boring task first. But you end up delaying that boring task because it’s boring.
I think what tempt us to look to events is that we like linear advancement. We like to think we always walk straight and every step we make we get closer to our goal. This might be a good thing sometimes, but sometimes it also hold us back.

I am not entirely sure about this subject and what I wrote. I just had a thought of why we like events, why we have anticipation to these events and why we promise ourselves to change only at a certain event. What do you think?

Happy New Year.