Eventually I got the right glasses, after two months of discussion -
woho, much better contrast than before, as the old ones weren't focusing
enough light onto my eye. I can see cleary now :) Moreover, I found an
excellent editor font (Monaco) at the Programmer's Notepad
Blog. I'm much more
productive with this font than with plain old courier, as it looks very
friendly, is easy to scan and very easy to watch at, especially with
larger code blocks as it's not too thick and heavy. I'm using it
currently on Windows at a font size of 10 pt and "Clear Type"
anti-aliasing enabled.

I've got my last exam on the 4th of october, after that, I'll post a bit
about my current "roadmap" as I'm getting sidetracked into another
project. I'll be hopefully able to continue work on both projects during
my studies, as it's likely that I won't have to work on the second
project on my own.

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!

Unicode

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 ...).

nivenScript

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.

Build tools

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.

The renderer

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.

Misc

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.

A few days ago, my RAID1 started to fall apart. I'm using a ASUS A8N-SLI
Premium mainboard with the nForce 4 SLI chipset. Sadly, this chipset is
not worth its money. The nVidia LAN firewall is simply broken, and the
RAID controller is unreliable - what could be worse for a RAID
controller. Read on for some ramblings about what will hopefully become
my next PC. I'm planning to switch over to a brand new machine mid/end
next year, and although I was looking forward to use a nVidia chipset as
I've been satisfied with the performance so far, I think that Intel is
gonna make it this time. Especially if it really turns out to be a Core
Quadro (recently reviewed on Tom's
Hardware)
which looks like a very good platform for development. Some other things
which are pretty sure is that I'll go for 4+ GiB of RAM and a RAID5
system. The RAID1 has been so far unsatisfying, performance wise it's ok
but that's it basically, and a RAID5 should give me a nive performance
edge at the same data safety level. I have doubts AMD/ATI will come up
with a competitive solution which is also reliable. After the adventures
I had with my current rig (which was by then cutting-edge technology
from AMD/nVidia) I'll wait at least 6 months until the Intel quad core
has matured a bit. If AMD comes with a quad core out at a similar time
as Intel, they can make it, otherwise they'll miss my time frame and I'm
really not willing to risk buying "beta" class hardware again.

Finally nVidia added transparency anti-aliasing support for most (all?)
GeForce cards. I tried the super-sampling AA on my 6800GT and it is
really looking very very good. The MSAA has problems with thin lines
(HL² fences for example) while the SSAA gives really good quality on
there, and as the SSAA is not really expensive I can only recommend it.
And finally the trees in Guild Wars don't flicker when you move around.
Well done!