My exams are mostly over (just one left) and I don't have to work for my company this week so I took the chance to get back into niven development. I've been playing around with unicode support and I have some ideas about nivenScript and the renderer, so read on!
Today I added basic support for unicode (back) into niven. Calls to the OS are now unicode where possible. Wasn't that painfull after all, mainly because I didn't use API calls as much as I though but rather the C++ library. Currently, all internal strings (logging, exceptions, etc.) remain ASCII encoded as I don't see a reason to make them all Unicode. Same goes for the configuration file. In addition to the OS support, I've added unicode support to the serialization system. All user-visible strings which are displayed by the renderer in one way or another are going to be unicode, so support in the serialization system was necessary (just wondering why I didn't add it right away ...).
I was thinking a bit more about how to add nivenScript to the engine, or
more precisely, how the wrapper is going to look like. The current plan
of attack is to add a special member function which returns an
IScriptable interface which can be used then for reflection etc. This
means that basically every class that can be scripted just needs to
provide this interface, so it's no big deal. Moreover, it doesn't
require modifying classes which aren't going to be scriptable.
The build tools are getting more and more mature. I'm planning to add
support for simple XML based driver files for batch building (currently,
you would do it like:
nbuild --tool=Package.Compiler [input1] ... [inputN] to process some
input files using the Package.Compiler). This will be done using a new
build tool so I don't have to break any existing interfaces; the new
build tool will take a job file and call other build tools to process
it. I'm not entirely sure about passing command line options through to
the build tools, the current plan is that all tools will be XML driven
if they need options and otherwise they shouldn't use command line
options. There is a rather hacky way to pass parameters that I've just
added, using a special command line switch like this:
nbuild --tool=Script.Compiler --params="optimize=3;debug=true" [input1].
Depending on daily usage I'll tweak those if necessary. The first build
tool (beside the package compiler and the meta-build-tool) will be a
Collada importer, as soon as I know how to represent data best for the
renderer. Moreover, the build tool needs a better documentation as it is
a "user-visible" part of niven. I'll like take a look at this next
month, when I have a basic renderer up & running.
I hoped to get on with the renderer during this week, but I'm stuck currently with how to create a render context best after my old engines never had a clean solution for it. The plan is to create a fully shader-driven renderer similar to what the Unreal Engine or Source Engine offers. The idea is that by providing a fully shader driven renderer I'm basically done with it and I'll "just" tweak the performance by removing certain flexibility (basic example: making geometry static by putting it into a vertex buffer). I want to focus on providing a robust renderer with good image quality and an orthogonal feature set, meaning that enabling one feature shouldn't break others. This will take at least till spring 2007. My development platforms for the renderer will be a 6800GT card for "reference" rendering, and an ATI Mobility X700 as the lowest supported system. Unfortunately, I'll be doing probably more development on the ATI card which means crappy drivers and nasty bugs, but I've got no other choice.
Python 2.5 is out, and an updated wxPython, too. I've upgraded locally and my build tools etc. continued to work without any problems. Python comes now with really nice and good looking icons on Windows. A new version of TinyXML is availabe (2.5.2) which adds support for "visitors". Again, the upgrade was painless here. Shameless ad: A university friend has updated his blog - take a look at the redesigned hehejo.de. He started with the same design as I did, so there are some similarities with my page, but I think it's interesting to see how diverse our page look although they share the same design idea.