Dimajix Developer Blog

Today i found a very interesting article about the future of OpenGL on OpenGL.org. The article describes ATI and NVidia thinking about the direction that OpenGL should take in its next releases (they also talk about the new features in OpenGL 2.1, but the proposed direction is far more interesting).

Their idea resembles the original goals of OpenGL 2.0 which propsed a new and clean approach offering backward compatibility only with an additional software layer. Unfortunately this idea was dropped in favor of backward compatibility. Now ATI and NVidia come up with essentially the same idea, the main difference is that they now call it OpenGL 3.0.

Among the features is a new object model (no integer handles any more that placed some special burden upon the drivers - they claim that up to 5% of driver processing time was spent for look-ups), programmable raster operations (stencil, depth and blendmodes will be shaders then), new state objects which will replace the glPush and glPop semantics and the removal of many obsolete features (including display lists wich should be replaced by VBOs).

But I guess we won't see OpenGL 3.0 very soon, if ever at all.

In my last entry I was talking about a neat tool generating reflection information for arbitrary C++ programs. Today I found another useful tool that is somewhat related to reflection, namely scripting. There are many scripting languages out there especially taylored for use with C and C++ programs (like Lua) or powerful toolkits for binding your code to a separate scripting language (like Boost::Python).

The tool called SWIG falls into the later category, but is much more powerful than anything I have seen before. Not only it produces the needed wrapper classes automatically, it has also support for 13(!) scripting languages. So processing your header files with SWIG enables you (or the users of your library/application) to use your work with 13 different languages at a finger-snip! (And of course, no one is holding you back to sell each language-binding separately...)

The only question left open might be what scripting is good for. Scripting allows end-users to interact with your program in an easy and convenient way and offers the complete power of a mature language at the same time. Many games use scripting languages in order to control the game logic, most operating systems use scripts (shell-scripts or .BAT files) for doing small jobs. Scripting simply opens a huge door for your developers and even for your customers to use your program in many new ways you never though of. John Ousterhout (creator of Tcl) also has written a paper that describes the benefits of scripting languages.

One important and useful feature is missing in C++: Reflection. Reflection is the ability of a language to acquire information about objects at runtime. Of course C++ has a typeid operator, but the use of the returned type_info is very limited and compiler dependant. What one is actually seeking for is complete information not only about class inheritance but also about all members and methods of each class.

Exactly this king of information offers the Reflex library developed at CERN. You can get all kinds of information about every object and class in your system, you can even instanciate new objects at runtime using string-literals describing a class and invoke any method of an object. One special advantage of this package is that it works in an absoultely non-intrusive manner, meaning that you do no have to change a single line of your code in order to get reflection. Instead of changing your code, Reflex relies on the gccxml parser that generates rich XML information about your classes. This information is then automatically transformed into some additional files containing cpp code containing all neccessary dictionaries and bindings to your code to enable full reflection.

Imagine the possibilities of such a system: You can easily integrate a scripting language into your program in a very generic manner if you use the rflection information provided by the Reflex library. WIth some additional work it should also be possible to serialise your objects to disk for providing persistent storage semantics. It even should be possible to implement some remote procedure calls building upon the reflection information provided by Reflex.