Skip to main content

Back on the OpenGL Track, Collada delayed

After a short break I'm back inside the OpenGL renderer for Niven|FSG. God it feels good to do OpenGL again ;) I didn't realize how much I missed this until I started with it again. I have good hopes that the renderer will be able to show something interesting around next month, maybe a bit later (probably after the holidays.) Some bad news: The Collada 1.4 specification (and the Collada DOM classes) are delayed again. If I read the posts correctly it'll be 45 days starting from the 21st November before they will release Collada 1.4. Bad luck, as I've been planning to make their ColladaFX the main effects format for Niven|FSG and now that will have to wait a bit longer.

Niven|FSG started

Yeah, people, finally Niven|FSG went into development! Be sure to read on to be the first who knows about it :)

What is Niven|FSG

Niven|FSG is the codename for a game being developed by a friend of mine and me using the Niven engine. We're gonna build Niven around this game, so the first edition of Niven won't be a general-purpose 3D engine (hence we call it Niven|FSG :)). The next iteration after this game will be surely much more generic than Niven|FSG, but we don't want to spend too much time in making Niven a generic game engine and rather push the game out of the door.


FSG is a game, with so unique and innovative gameplay I can't find words to describe it. Really, I can't! We expect the first beta version to be ready around late summer 2006. The game is gonna work under Windows and probably Linux, if we find someone who can port a bit of the low-level OS specific stuff to that platform. Don't hope that we'll support Mac OS X, BeOS or WTF-OS, we won't do that! (Except of course you break our EULA, decompile the game and port it the hard way with assembler only. If you manage to do that, we won't even sue you for decompiling :)). The rest is written in ISO conformant C++, so it should cause no porting problems. The 3D API will be OpenGL (suprising, isn't it?). The current state of development is that we've got some core stuff running, but we've got nothing you could look at (despite my .obj file loader which will be replaced by a COLLADA mesh loader as soon as the COLLADA 1.4 specification is out). The complete source is around 200 kb now, as soon as I get some LoC-Counting tool that works under Windows I'll add some counter that shows the development status. Anyway, I'm gonna release from time to time the commit counts so you can always see how busy we are ;).

GLExt2 goes OpenSource

After a long, long time I finally found some time to release GLExt2. GLExt2 is an utility that simplifies the use of OpenGL extensions. It basically takes an extension registry in text form (at the moment, I use the registry created by GLEW) and parses it into a XML file. This XML file is then further processed using a set of templates to generate a C++ class.


GLExt2 depends only on Python 2.4.x and wxPython 2.6.x. There are no other dependencies I'm aware of.

How to use GLExt2

First of all, you need to download (650kb ZIP) it. You might also want to get a more recent version of GLEW (you only need the GLEW source code, I bundled the extension files from GLEW 1.3). Put all GLEX extension files under /extensions. Now you're ready to run GLExt2. GLExt2 can run in either GUI or text mode, the file you need to start is the same in both cases: (don't start the, it will exit immediately). If you don't specify any command line option you'll start in full-blown GUI mode where you can click buttons and see a progress bar etc. :) Nice, but not really useful. Most people will like to use the command-line interface, which is also easier to integrate into your build process. Simply pass --gui=0 on the command line to surpress the GUI. You need also to define what will be build, use -x/--xml to generate the XML and -c/--class-header for the class headers. If you run with -c -x then GLExt2 will create the XML file first and the class second. Have fun and feel free to comment if you find it useful.


Support for GLX and GLU is not implemented. WGL support is working and tested. The class header can be built successfully with VC++ 7.1 without any special compiler switches.

Boosting your C++ tools

Here at the university surprisingly few people know about Boost, one of the probably most useful C++ libraries ever written (actually, it's a collection of libraries). If you never used it, give it a try. And if you're to lazy to read the "Getting started" document or you want a really brief start document, read on. (Or if Boost.Build refuses to build after you installed the latest DirectX SDK) This is a very brief guide how to get Boost running as fast as possible. I assume you have at least the following:

  • Windows XP
  • Visual Studio .NET 2003 (maybe 6.0 & 7.0 too)
  • Basic knowledge of Windows :)
  • Python in case you want to build the complete Boost library (this is what I describe here)

I also recommend you to get the "Command Here" Powertoy, it allows you to open a command line by right-clicking on a folder and selecting "Open command window here" which will be very handy :)


First of all you need to obtain Boost of course. In case you're not sure what to take choose the Windows Exe (the current version is: boost_1_33_0.exe), it's a sfx 7zip archive. Extract it to a drive where you have at least 3Gb of free space (I suppose you want to build all of it). Don't laugh, Boost takes quite a lot of space, the compiled binaries including all header files (compiled with 7.1, all in all around 3.5k files) take up 1,23 GB (1.323.074.806 Bytes) on my computer. You need to build Boost.Build first, which will compile the rest of Boost for you. Boost.Build is a modified version of the Jam build tool. Hence, you'll find it under /tools/build/jam_src. There it is, build.bat. For some reasons this build script does not work on my computer anymore (it used to work last month) - just after I installed the DirectX 9.0 SDK (October). The problem lies in the PATH environment variable. The DirectX SDK Installer added (in my case) F:\Visual Studio .NET 2003\Documentation\DirectX 9 SDK (October 2005)\Utilities\Bin\x86 - the braces around October caused the build script to fail. In such cases you can still get a precompiled binary (or you remove the DirectX SDK from Path). Copy the bin.ntx86\bjam.exe into the topmost directory of your Boost folder.


Now, you need to "install" Boost. When installing Boost, you have several choices, I recommend you to specify a "Temp" directory in which Boost will put the object files, and a "Install" directory where it will put in the *.lib, *.dll and *.h files. Instead of talking about the options (you can read them for yourself) here my build_boost.bat which I use without modifications since Boost 1.3: bjam "--prefix=F:\C++\Boost" "--builddir=F:\C++\Temp\Boost" "--with-python-root=C:\Python24" "-sPYTHON_VERSION=2.4" "-sVC71_ROOT=F:\Visual Studio .NET 2003\Vc7" "-sTOOLS=vc-7_1" install Replace --prefix with the directory that should contain the clean Boost binaries and headers, --builddir with the temporary directory, --python-root with your Python root (how surprising :)) and VC71_ROOT with the directory to Visual Studio 2003 (use VC7_ROOT for Visual Studio 7 and MSVC_ROOT in case you use 6.0). TOOLS will be vc-7_1 for 7.1, vc7 for 7.0 and msvc for 6.0. That should be enough to get you started, be patient, the compiling will take some time. Have fun with Boost! In case you have questions don't wait and comment :)

OpenOffice 2.0 is out

Back in the web, and some great news right away: OpenOffice 2.0 is out. I've downloaded it maybe 2 hours after the release with no problems and excellent speed, seems their mirrors are more than up to the task (>500kb/s download speed). Well done guys!