it's time for me to share some information about the development again. This time, I won't even start to complain about how little of free time I do have, but I'll rather put all the energy into the actual report.

Okay, so what's new since the last report? Well, a lots of things, and I'm sure that I won't remember them all, but I'll try hard to mention everything that happened.

First of all - a huge amount of changes were done in the engine design. I've completely rewrote almost all the code I wrote as C++ beginner, and I also did a lot of refactoring on the new code (>=2011) as well. Why? Because I'm preparing the source code for (semi-) public development, and I don't want to find out that the whole engine sucks in the very first email, after it get's released

Anyway, the engine is now more modular and easier to understand. (I hope that) I moved all the Arcanum specific code (e.g. file format specifications, loaders, etc) into new module, so the engine should be now reusable for new games.

Another huge amount of changes were done in the renderer subengine. It was not only completely rewritten, but the most important change is that it's now independent from any graphics API. Originally, everything was bound to OpenGL API, and now it's possible to add support for Direct2D/3D, and other possible graphics APIs - with a little work (I hope).

That's all, about reinventing the wheel. Now about some other things.

All the development files (i.e. source code, assets, and other stuff) were scattered across my hard drives, DVDs, and backups, and it was almost impossible to find anything. There were also a lots of duplicated files. In other words, it was just a mess.

I fixed that too - I've moved everything into one root directory (which is on hard drive with RAID1 array - so it's much safer now), then I deleted all the duplicated files, cleaned up it a bit, and put it under revision control (using git).

It took me a week to do that all - such a mess it was.

Anyway, there are also some bad news. The progress of the development isn't as far I expected, because in early 2010, I was planning to have an alpha version ready before the end of 2011, and as you can see, it's not even nearly the alpha testing stage.

Even worse, the source code still won't compile, because there were a lots of changes done in the code. But I'm working on it, and once I fix that, there will be rapid speedup in the development again. Also, from now, I'll be using more third-party libraries to speedup the development a little bit, so there really should be at least a tech demo released this year (I hope).

@Koorac: If I may ask, do you have any experience with parsing C++ files? I'm currently working on tool called MetaGen, which should generate some meta data about the classes used in OpenArcanum, also with automatic cpp to lua binding.

Currently, I'm using helper macros to generate the properties and lua bindings, but I think that it's not a really nice solution, here is an example:

-I use Qt alot and that has MOC which generates a cpp file containing all the information about a class that you want to export.
That can then be used for bindings. It can be used without having to inherit from QObject (which uses a bit more memory).
Things like getting/setting properties/calling methods/exporting enums with names, etc would work. It is like lightweight reflection for C++.
Linking to QtCore would be like ~4MB (if no other process is using it). If you link statically it will probably be a lot less, since only the MetaType system is used.
Pros would be that it is a proven system backed by a company and all the code in the library is unit-tested. Writing an own thing my be buggy.
However I remember that you didn't want to use Qt for some reason, so this may be a no-go. However it may also be possible to just generate the code and use that without
linking to Qt (not sure if the generated code uses Qt types anywhere.

-Another possibility would be to parse the files using clang:http://amnoid.de/tmp/clangtut/tut.html And then generating whatever is needed for the bindings. I think that using clang library for the parsing might be a good idea, since parsing C++ is really difficult.

Personally I would go for Qt (only core, without GUI), but ultimately it is your decision.

I think it is a very good idea that you want to use more third-party libraries, writing your classes and ensuring they are correct with unit tests is a very long procedure.
What libraries were you planning on using?

-I use Qt alot and that has MOC which generates a cpp file containing all the information about a class that you want to export.
That can then be used for bindings. It can be used without having to inherit from QObject (which uses a bit more memory).
Things like getting/setting properties/calling methods/exporting enums with names, etc would work. It is like lightweight reflection for C++.
Linking to QtCore would be like ~4MB (if no other process is using it). If you link statically it will probably be a lot less, since only the MetaType system is used.
Pros would be that it is a proven system backed by a company and all the code in the library is unit-tested. Writing an own thing my be buggy.
However I remember that you didn't want to use Qt for some reason, so this may be a no-go. However it may also be possible to just generate the code and use that without
linking to Qt (not sure if the generated code uses Qt types anywhere.

-Another possibility would be to parse the files using clang:http://amnoid.de/tmp/clangtut/tut.html And then generating whatever is needed for the bindings. I think that using clang library for the parsing might be a good idea, since parsing C++ is really difficult.

Personally I would go for Qt (only core, without GUI), but ultimately it is your decision.

I think it is a very good idea that you want to use more third-party libraries, writing your classes and ensuring they are correct with unit tests is a very long procedure.
What libraries were you planning on using?

Oh hey, thanks for the reply.

I'm actually aware of their MOC, but I need/want to generate more meta information than the MOC generates (for object de/serialization, for example), thus I need to write own generator. And isn't there only support for Javascript binding in Qt? Or does it also supports Lua? Or is it possible to inject some proxy layer there for Lua bindings? I honestly don't know.

Also, I would like to use Qt, but it's just too heavy for such a lightweight engine. And if I start linking some parts of Qt (like QtCore module) to the engine, then there is no reason why I shouldn't link the whole Qt framework to it, as it would make the development easier. Then I could start replacing all my code with Qt's alternative, because my code might contain some bugs. Do you see where it's going?

Anyway, thanks a lot for the clang idea, it seems to be the solution I'm looking for. That tutorial also looks as good place for start.