Archive for January, 2010

Fun with dynamic casting

Friday, January 29th, 2010

Polymorphism allows for different function implementations to be called, depending on values only known at run time. For instance:

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);
};

Out of the box(bug)

Wednesday, January 20th, 2010

When you draw sprites you are thinking in 2D. I was using DirectX’s ID3DXSprite interface to draw sprites. I had to scale up a sprite to cover the whole screen. The sprite can be in different resolutions. If the sprite is quarter the size of the screen, then it needs to scale up by 2.
When I scaled my sprite by 2 everything worked, but when I scaled it by 4 it was not visible. What was the problem?
The sprite draw call gets a 3D position as a parameter, so I passed the x and y I needed and have put 0.5 for the z. I don’t remember why I did that.
It turned out that when I scaled the sprite by 4, it scaled the z component of the position to the value of 2. It meant that the sprite, which is actually a quad, was outside of the viewing frustum.
In the case of the sprites rendering, the viewing frustum is a box of the dimensions [0..Width]X[0..Height]X[0..1]. Anything with a z value greater than 1 will not be visible.

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.

Base Code 2

Friday, January 15th, 2010

A full rebuild of Labyrinthica takes quite a while and some of my code goes way back. This has led me to the decision of trying to revisit my code of Labyrinthica, with a focus on my next project(TRG) as what will be the product. I plan on blogging on how this will go.
A few things I have learned from my new workplace(Microsoft), is how to profile builds. For instance, the use of precompiled headers, and turnning on the build timing option in VS express 2008.
Here is an article talking about this.

Who moved my monitor(cheese)?

Tuesday, January 12th, 2010

I was starting to work at a new workplace last week. They have set me up a temporary desktop computer.
It was placed on a “table corner”, where two perpendicular tables connect. The set up was inconvenient. The monitor was placed far into the corner, and the mouse and keyboard cord barely reach the table’s edge.
Since the monitor was far, it was making my eyes tired. I don’t know exactly what I was thinking, but I rationalized why I should not try to pull the monitor closer.
At first I thought that because the mouse and keyboard cords can’t be pulled, there will be a problem with the monitor cord as well. Then I was told that I will get a new monitor today, so I said after I will get the new monitor this problem will be fixed.
I then talked about it with my boss, and while talking to him I figured how silly it sound that I just didn’t check or try to pull the monitor closer. I tried to gently pull the monitor and found out there was a lot of loose cable.
We some time rationalize things or find excuses to not try things because of a future event we are looking forward to.
It is a really important quality to be able to try things out even if you have no prior knowledge if it will work or how you are going to do it.

Accessing privates without ‘friend’(c++)

Tuesday, January 5th, 2010

Here is a neat little way I found to make one class access the privates of another class, without using friend or direct inheritance. Take a look at this code:

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.