July 12, 2009

C++ Reflection

Posted in Computer Graphics tagged , , , , , , , , , , , at 10:48 pm by sagito

Today I faced a different problem while trying to build an external interface for the Conspiracy Engine… As it was built on C++, which is a compiled (not interpreted) language, the compiler does not have the concept of reflection. In the first place, what is reflection? Reflection is a technique that makes a language able to know, observe and modify its own structure and behaviour. For example, if I have a class A that wants to know which methods and variables are in class B, I just ask the compiler to tell me. This happens, for example in C#, where we can ask the compiler for class methods, variables, and even execute the methods if we want.

Problem is: There is no direct support for this in C++… However, I need that, because my intention is to build an external editor that can interact directly with the engine like the CryEditor, for example. So, I’m trying to find a solution! There are several ways of attempting such a thing. The first one is to read through the debug information… This is not viable because different compilers use different approaches for debug and the program would have to be always built with debug information (which is huge).

Second solution would be to create a compiler that supported reflection for C++… I have already create one (not for the C++ language!) and I guarantee that it is not something neither pretty to see nor easy to implement. Third solution: Create a specialized pre-processor that could build over the class descriptions… This solution could be viable… However, parsing the C++ language is not trivial and would require a two-pass-process which would introduce a huge overhead.

So, there is no solution for this problem? What if the engine had a specialized class that would store the data for reflection? Every class that derived from this base would register their variables and methods in a global storage that could be accessed from any other class. This is not the real reflection that we are to, but it seems like a nice approach. And it contemplates the cases in which a variable (or class) is sealed, i.e., not accessible through reflection. In that case, the class simply does not register its variables or methods! This approach seems to be the best one so far and I have already implemented it on Conspiracy.

So far it is working fine! 😀 I should give you some news very soon about the new editor for Conspiracy! 😉

Advertisements

July 5, 2009

New Stuff!

Posted in Computer Graphics tagged , , , , , , , , , , , , , , , , , at 10:58 pm by sagito

I’m bringing you some news from the Conspiracy Engine! Since yesterday, I have been able to implement three new important things in the engine. The first is a TAL (Top Abstraction Layer) that manages the engine almost totally. This was implemented through several Adapters and a Facade pattern. It is working nicely now, and most of the code that was in the main.cpp could be hidden under this layer now, simplifying the whole thing. I will try to create a configuration (scene-graph like) file that will be loaded by this class and automagically presented. The whole engine is already prepared for that, it is just a matter of putting things together.

I have also implemented geometrical transformations. Due to the overall organization and architecture of the engine, this was much quicker than I expected and took only about fifteen minutes to complete.

Finally, I have managed to get the Picking-related stuff working. Picking is always a big headache because it envolves a lot of maths (matrix inversion between three vectorial spaces, conversions, etc), and also because it is a HUGE design problem! Why? Well, as some of you should know, Picking is the possibility of selecting an object in a 3D world through the click of the mouse. However, the mouse “lives” in 2D space while the scene is usually 3D. So, the mouse coordinates are caught up in the Input layer and must be propagated to the Object Rendering layer in order to check if some object was intersected by the ray generated by the mouse click. As you can imagine, crossing several layers many times and returning to the interface is a quite tough design job…

However, my approach tried to obtain not only quality in the design (without violating any abstraction encapsulation) and also performance. As I already need to go through every object while drawing, I figured that I could use the drawing cycles to perform picking. As every function returned void at the time, they now return the set of picked objects! This way, I shared as less code as possible (in a Aspect-Oriented Programming way) and still managed to obtain the most of the engine performance!

Now I shall work in the textures. There is not much work left, so that when I finish some last things, the game should be born! 😀 Promise that will keep you posted… 😉