Dimajix Developer Blog

A new version of Magnum has been finished and is available for download. Currently only the new framework has been published, but the newly created small 3d model viewer will follow soon.

This release of Magnum contains the following changes:

• A totally reworked media module which allows streaming and playpack of ogg vorbis files.


• A simple HTTP client.


• A simple 3d model viewer.


• A new PhongShader class.


• Lots of bugfixes, especially concerning memory managment.

And some more good news: Since I made a release-script for Magnum today, a release is much simpler yet, thus you can expect faster updates from now on (of course if I have enough new features and/or bugfixes worth a release).

Today I had an important lesson about a subtle detail that hides behind overloading the new and delete operator in C++. Actually in most cases, you do not need to overload these operators, but the possibility to do so comes in handy if you want to work with your own allocation schemes. So the following code is just legal in C++


class Myclass {
public:
Myclass();
~Myclass();
void* operator new(size_t size);
void operator delete(void* );
};


Continue reading "operator delete != delete operator"

I made some big progress with the media framework API that will be part of Magnum. Although the currently implemented features are rather simple, the whole architecture is very flexible and powerful, working with so called media nodes which can be connected together. So far a simple WAV decoder for uncompressed WAV files is included plus an Ogg Vorbis decoder using the original vorbisfile library available on www.xiph.org.

Of course I was also thinking about a MP3 decoder, but finding an appropraite library under a BSD/MIT style license is a tough task - finally I decided to use mpg123, a simple MP3 player for UNIX and Linux (there is a slightly older version under a BSD style license as opposed to the newer GPL license). But as a matter of fact, mpg123 is not a library, but a small command line program. So I started to convert mpg123 to a decent lib, but that is really some hard work, as mpg123 uses lots of static variables (which are a no-go for a"decent" lib as these will prevent of playing two mp3's simultaneously). So I decided to postpone the "libmpg123" project for a little while.

Meanwhile I came across the idea about streaming OGG files (and maybe later MP3 files) via HTTP directly from the web - the stream based I/O architecture of Magnum should make these things easy, so I started to write a small HTTP client, and it turned out to be simpler as I thought, as long as one only uses HTTP 1.0. HTTP 1.1 supports so called content encoding (like gzip and deflate) for better bandwidth usage, but these encodings make life a little bit more difficult, so I decided to stick to HTTP 1.0, which is enough for most tasks.

When I finally finished the HTTP classes, to my surprise they turned out to be really fast: For a test I uploaded a 200MB file to my local Linux based webserver and when downloading that file, I got a bandwidth usage of about 95% (100MBit LAN) on my Windows box while the CPU load was only about 3-5%. For a comparison: Firefox downloaded the same file at half the speed, and wget was able to utilize the same amount of bandwith but used about 20% CPU power.

Stay tuned for the next release of Magnum, that should only a couple of days from now.

One of the next very useful features to be added to Magnum will be audio-support. While this sounds rather easy, it turned out that doing this right is a more complex task than I had originally thought. The difficulty lies in the fact that I want to do it "right". So what does that mean?

Actually I am working on the complete media framework of magnum - even the last version only included a skeleton which I am currently trying to flesh out. In order to give you an impression of the complexity, let us have a look at the features that should be included:

• Support of container formats independent of codecs


• Support of multiple tracks within one file


• Support of different codecs


• Support of audio-data


• Support of video-data


• An easy to use API with media nodes that do all the work

I have already finished the media node API, but still missing is the complete container file API and a format descriptor that is easy enough to use and flexible enough to cover most cases. It should be easy to play a simple WAV file and a complex AVI with multiple tracks. My current design has the following components, but I am not sure if this will be my final decision:

• A media container file, having a short description about the container format used.


• Each media container file can have multiple tracks, each either audio, video, text or generic data.


• Each media track can use its own codec.


• Each codec can specify one or more possible output formats.

As you can see, this is the really complicated version of "playing a WAV file".

Hopefully I will finish the media framework within the next couple of days, bein able to play a short WAV file, maybe even an Ogg Vorbis file (MP3 files probably won't be supported due their license restrictions).

It's already some months since the last demo for Magnum has been published. Unfortunately a real new demo is not ready yet (I am even not working on any), but the library has been extended by many new features including

• Transparency support


• Picking


• New input methods for VR devices like the P5 Glove


• Camera Layers


• many bugfixes and improvements

Most of the work is behind the scenes, but the biggest new feature probably is picking, which is not only implemented in the model classes, but also in the scene3d universe class which enables effcient culling of nodes that cannot be hit by the pick-ray.

You can download the newest version of Magnum here and the newest test can be found here.

A new OpenGL specification for an extension has been finished by the "ARB superbuffers workgroup". The new extension called EXT_packed_depth_stencil is about a hardware-native format that handeles the depth-buffer and stencil buffer in one interleaved buffer. This extension allows to read from/write to such an combined depth/stencil buffer with one function call instead of two plus no conversion of the data is needed any more, which in turn should speed up such operations. Plus this new packed data format can be used together with the EXT_framebuffer_object extension which allows an application to render directly to a texture.

Currently I don't need this extension myself, but it is important to all those people out there who wanted to render to a texture using the stencil buffer - this was not possible on many consumer level graphics cards due to the lack of an appropriate render target format.