Finally: New Magnum Developer Release

Thursday, December 7. 2006
OpenGL
As I already promised in this blog and in some emails to various people, I prepared a new developer release 0.4 of my framework "Magnum". It already contains a lot of changes and supports SCons for building it.

I also packed another archieve containing all data sets that are used for the demos - unfortunately you really need it in order to build the framework and all examples using the build scripts.

Among the changes are:
  • SCons as build system.

  • A much better directory structure.

  • Much more pure virtual interface classes.

  • XML parser and DOM-like document model.

  • HTTP Server functionality.

  • The skeleton of a meta-compiler for reflection and more.

  • Lots of other changes that even are not documented in the changelog

I am also thinking about publishing a copy of my subversion repository online, so you can follow the development and access the most current version - but I am not sure about that and I currently don't have enough time to set up a replication mechanism.

What am I doing?

Monday, November 27. 2006
Programming
I really tried hard to post an entry onto this blog once a month - almost 9 months ago. Now I will retry to populate this blog again with some information. So what am I doing at the moment? I am still working a lot on Magnum in my spare time. Expect an intermediate release soonwith lots of changes inside and outside; among those are:

  • Switch to subversion as a source control system.

  • Switch to scons as a build system.

  • Removal of NVI (non virtual interface) pattern from API.

  • Basic functions for a generic meta-compiler.

  • Added some kind of unittests.

  • Lots of API refacturing and bugfixing.


As you can see, although I haven't updated Magnum for a while, I really have been busy making it a better framework. I guess the rework of the API and the final metacompiler won't be ready for some time, so there will be an intermediate release (I don't want to say "development release", as all releases are mainly for developers) giving a glimpse of the new features mentioned above. And I promise to you, the metacompiler will be really hot!

Inheritance, Constructors, Virtual Methods and typeid

Wednesday, May 3. 2006
C++
When working with inheritance and virtual methods, there might be some surprises when one tries to call a virtual method inside a constructor - and this is the reasons why one should never ever call virtual methods inside a constructor or inside a destructor.

Consider the following simple code

class A {
public:
  A() {
      printf("A::A() calls ");
      f();
  };
  ~A() {
      printf("A::~A() calls ");
      f();
  };
  virtual void f() {
      printf("A::f()\n");
  };
};


class B : public A {
public:
  B() {
      printf("B::B() calls ");
      f();
  };
  ~B() {
      printf("B::~B() calls ");
      f();
  };
  virtual void f() {
      printf("B::f()\n");
  };
};


void main(void) {
  B obj;
  obj.f();
};


Continue reading "Inheritance, Constructors, Virtual Methods and typeid"

VBOs or Display Lists

Tuesday, April 11. 2006
OpenGL
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...

New cast operators with additional features

Friday, April 7. 2006
C++
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"

A new Direction for OpenGL

Friday, March 24. 2006
OpenGL
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.

Scripting your Applications

Monday, March 20. 2006
C++
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.

RTTI and Reflection for C++

Wednesday, March 15. 2006
C++
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.