Dimajix Developer Blog

Silently, without a headline on OpenGL.org, five new extensions have been completed and added to the OpenGL Extension Registry:

• EXT_framebuffer_blit. This extensions allows to copy a region from one framebuffer object into another framebuffer object ("blitting"). It is especially useful with the next extension, which in turn would be useless without this one.


• EXT_framebuffer_multisample. This extension finally allows to create multisampled frame buffer objects. As a direct usage of the frame buffer objects as textures or backbuffers is not possible, it heavily depends on the previous extension.


• WGL_3DL_stereo_control. Some stuff for controlling 3d stereographic shutter glasses.


• EXT_stencil_clear_tag. This seems to be a rather esoteric extension for saving bandwidth on the low end generation of PCIe cards that use main memory as a gaphics card resource.


• EXT_texture_sRGB. This extension adds a new texture format for representing the non-linear sRGB colour space. Maybe this extension is useful for hardware accelerated image processing - I really don't know much about its usage.

As you can see, the two probably most valuable extensions (at least for high quality realtime 3d graphics) are EXT_framebuffer_blit and EXT_framebuffer_multisample.

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.

By chance I stumbeled over a very useful website offering old versions of programs for download. You might ask why some people might prefer not to use the latest sotware? Well, not every version upgrade automatically means better software. Plus modern software tends to be heavywight with tons of options and unnecessary bloat - while earlier versions of the same program were fast, easy to use and small.

And especially web-designers might want to take a look at that site, because there are tons of old browsers available. These form an important tool for all HTML-people in order to verify that their pages can be viewed not only on a broad base of different browsers, but also on different versions of the same browser.

So, here is the link: http://www.oldversion.com/ to that important site.

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).