the first level of Star Guard

the same scene in the editor

A few things came together that caused me to make this level editor:

• I was looking for an excuse to do something interesting with QML.
• Star Guard is a great game and stores its levels in friendly, easily accessible XML files.
• When I emailed Loren about the project, he allowed me to use some of the game’s artwork.

The whole thing was surprisingly easy to do, took a couple of days and amounted to less than 1200 lines of code – one half of it QML and the other C++.

If you don’t know about QML: It’s a fairly new part of the Qt framework, essentially an extension of JavaScript to build user interfaces declaratively – and great fun to work with. All the details can be found on its documentation page and if you want to get started, the Qt 4.7 beta1 packages have just been released.

The editor uses QML to describe every aspect of the user interface. It’s turned out to be very useful in the beginning of the project when the editor was still QML-only and the interface layout and behavior changed a lot. It also means that it’d be very easy to redo the user interface now – even for someone without any C++ knowledge. Also, not having to recompile after every step simply makes fiddling with the UI a lot more pleasant.

Of course there’s the disadvantage of not following the native look and feel. But no one ever complains that most games don’t use it – and I don’t think it’s necessary for a level editor to look just like your spreadsheet application either.

The C++ part deals with the backend work, like providing a model that holds the map, a QML item that paints it, and loading from and saving to files. I used the QML plugin mechanism to expose these to the UI code.

The editor is fully functional; I consider it done and will not continue working on it. If someone wants to improve it or base his own tile based level editor on it, feel free! I release the code under the Boost Software License 1.0.

Linux binary (64 bit) and source code (12 MB)
Windows binary and source code (10 MB)
source code only (.tar.bz2, 20 kB)
source code only (.zip, 30 kB)

This is not a failing in itself. Indeed most users will never have the need or desire to compile their compiler from source. Yet it also prohibits testing patches for the front-end, makes debugging nigh impossible and generally complicates helping with DMD’s development.

The alternative – and often the only alternative if your target is not x86 Linux or Windows – is GDC. David Friedman took the open front-end and tied it to the GCC back-end, he even supports D 2.0 to some extend. While it works well and is fully open source, it has, unfortunately, remained a one-man effort. For me it was a combination of GCC’s daunting code base and the fact that there had been no activity for several months that stopped me from helping out.

Instead I eventually joined a different project: LDC. It is similar to GDC in that it also takes the open DMD front-end and aims to combine it with an equally free code generator. The back-end, though, is different: as the name suggests LDC emits LLVM bitcode, which can be compiled to native code, but could also be used for Just-in-Time compilation among other things. I’m also happy to say that even though LLVM is a large and ambitious project, it remains surprisingly easy to learn and work with.

Almost the first thing I did when I started contributing to LDC a few months back, was to integrate Thomas Kühne’s exhaustive DStress test suite with LDC: it is very useful for finding bugs and regressions and can even serve as a sort of crude progress indicator (crude because there is no relationship between number of bugs and number of tests; there are about 1000 tests for inline assembly and only 30 or so for exception handling). As you can see, there are still a handful (517 at the last count) of regressions with respect to DMD, but their number has been decreasing steadily.

In the last months, Tomas Lindquist Olsen, who started the project about a year ago and is responsible for almost all of its existing functionality, and I have added the last major missing parts to the compiler: inline assembly (thanks to David Friedman for the asm parsing and rewriting code!), exception handling and the synchronized statement are now supported. With these out of the way, goals for the future are squashing bugs, fixing some linking issues and getting LDC to work properly on Windows.

Speaking of other platforms: As Tomas and I both develop on x86 Linux, other configurations didn’t get much testing yet. Some people reported partial successes on FreeBSD and Sparc but more testers would be welcome. You can generally contact us by email or in #ldc on freenode. All in all, we’ve made great progress and if we can keep it up, LDC will be in the same league as DMD and GDC soon.

Long story short, I needed a way to read and write the MAT files that MATLAB generates and loads with the ‘load’ and ’save’ commands. Using the C API directly seemed cumbersome and error prone, so this C++ wrapper was born.

Download it (4 kB) as .tar.bz2 or as zip.

A basic use case looks like this (also check out test.cc):

#include "matlabfile.h"
using namespace MatlabUtilities;
 
File matfile("some.mat");
std::vector<double> vec1;
matfile.read<Types::real_vector>("v1", vec1);
 
double[100] vec2;
matfile.read<Types::fixed_length_real_vector<100> >("v2", vec2);
 
matfile.write<Types::string>("hw", "Hello World!");


Not all MATLAB types are implemented (check Types namespace in matlabaccessors.h for a list), in particular real matrices with a column and row length different from one are missing for two reasons: I didn’t need them for the job and you probably have your own preferred matrix type anyway. But don’t worry, the template-design makes it easy to add these missing features. What needs to be implemented is

struct real_matrix {};
 
template <>
struct Reader<real_matrix, MyMatrix> {
    static void read(mxArray* var, MyMatrix& result);
}
 
template <>
struct Writer<real_matrix, MyMatrix> {
    static mxArray* write(MyMatrix& source);
}
 
template <>
struct TypeCheck<real_matrix> {
    static bool typeCheck(mxArray* var);
}


where the ‘read’ function reads data from the mxArray into result, ‘write’ returns a new mxArray filled with source’s data and ‘typeCheck’ returns true if the mxArray contains a real_matrix. With these template specializations in place you can use the new code like this:

MyMatrix mat;
matfile.read<real_matrix>("somevarname", mat);
matfile.write<real_matrix>("someother", mat);

Similarly, you can add a new reader to say ‘real_vector’ to accomodate for your own vector type.

The code snippet only contains code for reading and writing data. Other management functionality, like listing all fields in a MAT file is not implemented. I hope it will nevertheless be useful for someone.