Dimajix Developer Blog

For all those of you who remember the fantastic game "Another World" by Eric Chahi from 1991, there is a new hi-res version out for Windows. You can download a shareware version and upgrade it to the full game for only 7 EUR! Don't miss that opportunity, at least you should check out the free version in order to get an impression of one of most atmospheric games from the old days.

Today, there was the question if VBOs are really as fast as display lists in OpenGL. Normally one would expect that VBOs should be at least as good as the old methods, but it seems that depending on the batch size and on the number of batches, the opposite might be true. I found a page with a small tool for measuring performance. At least on NVidia cards, VBOs do not seem to be the ideal solution for static geometry, whereas on ATI ther performance of VBOs should be almost equal to display lists.

So maybe I have to include another render path in Magnum using display lists...

C++ already has a rich set of casting operatos, ranging from old-style C casts, over static_cast, dynamic_cast and the almost-never-to-be-used reinterpret_cast. Sometimes it might be convenient to have something similar like a dynamic_cast but with another behaviour if the cast fails. For example one might want to get an exception if a specific cast is not possible.

It turns out that this is pretty easy using templates with the following code

template<class T,class S> T* throwing_cast(S* s) {
   T* result = dynamic_cast<T>(s);
   if (!result)
     throw bad_cast_exception();
   return result;
}

ClassA* a = new ClassB();
ClassB* b = throwing_cast<ClassB>(a);

But we still can do better than this, because we might want to configure which exception should be thrown on a casting failure. The code above can be easily modified to:

Continue reading "New cast operators with additional features"

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.