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