Tool coding

In late April/early May I had a bunch of spare time on my hands. Naturally, I did what anyone would do, and started working on a cool GUI for creating and editing demos and intros and whatnot. This wasn’t a particularly new idea.

The first GUI we created was to do all the meshes and animation for our 64k intro Pure. John-Pierre made this really elaborate tool (in DOS, even!) that was basically a combination of hard-coding C code and data combined with some form of interactive GUI. From what I remember, it wasn’t the most easy to use piece of software ever invented, but it worked quite well. I can remember I was especially proud of the perspective correct w-buffered texture mapped triangle rasterizer. Too bad we placed 4th in the 64k competition, though. Looking back I think it would’ve helped if the intro had looked slightly less ugly :).

In the years following that we had several aborted attempts at creating this big unified tool again. As a first step, John-Pierre coded up the GUI for the texture-generation part of our system and called it “Picasso”. The core of the system was quite neat, it was basically similar to Photoshop with support for layers, blending modes and with full floating-point precision. Because of the floating-point usage it was fairly slow as well, but we used it to good effect in Sonnet in 2001. The problem with the “Picasso” approach, though, was that it wasn’t exactly a unified approach. Although it was a pretty cool solution for generating textures, there was no way of generating meshes, doing animation or generating sound. In fact, the animation in Sonnet was done using a fairly ghettoesque Win32 based tool grafted onto the main executable. Clearly, we needed some kind of unified approach.

Now, a few months before we released Sonnet, the utterly excellent DemoPaja was released. Although I never did anything useful with it, I loved the fact that it worked so well and, more importantly, that it was so well-engineered. Although it wasn’t really suited for actual content creation as it was basically ‘just’ a timeline-tool, it had quite a few features that we’d wanted to integrate in our own system. Stuff that seems trivial, like Undo/Redo support, but which turns out to be slightly more finicky than one hopes.

I guess it was a few months later that we got to see Werkkzeug which was geared towards actual creation. The problem with Werkkzeug though is that it’s fairly hard to use and quite a non-standard interface. The reason for this turned out to be that Chaos implemented the entire GUI framework from scratch, since he felt that the time spent learning an existing framework like MFC (I’m paraphrasing from one of his seminar, though) would be just as much time required to reimplement everything.

Well, we certainly didn’t feel that way. Our tool was going to be based on the frameworkingest framework of them all, the .NET framework. Yeah. Bad idea. More about this in the next update.