After running Drupal for 3 years, then Joomla for another 3 years, I have now moved my
website to WordPress — after almost picking Drupal again. So here’s the obligatory
write-up of my experiences, why I switched and where I think the problems lie in those
In August 2006, after trying about a dozen CMSs, I went live with my website built
It promised the greatest flexibility and had a very active community with countless
I was happy with that, for a time. Drupal enabled me to define my own category trees, article
types and mix WYSIWYG editors with filters for highlighting code, disarming HTML code in posts
and letting users write comments.
I’m pretty sure that by now, everyone reading this blog has heard of or probably
even played Minecraft himself. It’s a sweet little game
that tosses you into a simplified world that you can freely (and easily!) shape
in any way you want. Your tasks: feed yourself, keep monsters out of your buildings
and build something remarkable.
Minecraft can, of course, be played with any number of players online. All you need
is a server with shell access and Java on it. If you also have Mono on your server,
you can use McMyAdmin, a very convenient web frontend for
the Minecraft server to manage users and perform automated backups.
In spring this year, I began work on a moderately sized business application.
The time from learning what the program should do to the first prototype were
less than 2 weeks. To pull it off, I basically ditched any sane development
practice and started throwing code at the problem as fast as I could.
The application required a client/server model and the server had to store
its data in a database. At that point in time, I knew about ORMs but had never
used one before, but hoping for the best, I picked Microsoft’s Entity Framework because it had
a visual designer and looked like I could just drag & drop my data model
together and then figure out how to perform queries.
It fell flat when I noticed that I could only choose between TPT (Table
Per Type) and TPH (Table Per Hierarchy) globally
for the whole freakin’ model. So I tried NHibernate and
quickly rebounded due to its learning curve, resorting to writing SQL queries myself
and loading them into objects with a very basic class mapper that I had written for
another, much smaller project some time ago.
It was tedious work, but at least hacking away for two hours got you two hours further,
not one step forward and two steps back figuring out the ORM. And so I managed to get
the prototype done with two all-nighters. In autumn, when the heat was off, I decided to
do the database properly, using NHibernate…
My last contact with Ogre 3D had been in 2008, when I had created
an experimental x64 build (back then, OpenJPEG, FreeImage
and some other dependencies didn’t yet build in x64 by default).
This worked out fine, but I didn’t find the time to actually do anything with Ogre.
Finally, during the past weekend, I took a closer look at Mogre,
a C++/CLI-based wrapper that enables you to use Ogre in .NET languages.
A few hours ago, I uploaded a new release of the Nuclex Framework
to CodePlex. There has been an intermediate release, R1323, which I didn’t
announce here because it was more or less just a stop-gap measure to
stop reports for issues in the old (old, old) R1242 release where my
Nuclex.Input library was still subclassing XNA’s Window.
This is what changed from R1242 to R1404:
Thanks to a generous contribution by Adrian Tsai, the TrueType importer now accepts
standard Windows font names – this is a big step towards being a drop-in replacement for
XNA’s own sprite font importer.
The TrueType importer now lets users choose different hinting algorithms. No hinting
will result in MacOSish blurred text that stays true to the font’s metrics. The
auto hinter from FreeType is a nice compromise between forcing strokes into a pixel
raster for sharpness and retaining the font’s look (and imho the best option).
Native will produce a perfect match with Windows’ font rendering, producing sharp
letters that may deviate from the font’s actual metrics a bit.
You can now decide whether SpriteFonts imported by the TrueType importer are centered
on their baseline or on their upper end (like XNA). This, together with the improved
font name lookup turns the Nuclex TrueType importer into a 100% drop-in replacement
for XNA’s font processor.
Nuclex.Input’s game pads now provide a method .GetExtendedState() with
which you can access all of DirectInput’s 128 possible buttons, 24 axes and 8 sliders.
I designed this so that there’s zero overhead if you don’t use the
.GetExtendedState() method. The ExtendedGamePadState
already normalizes axes for you (from -1.0 to +1.0 for axes and 0.0 to 1.0 for sliders)
and in general is much nicer to work with than using DirectInput directly!
Nuclex.Input now supports TouchPanel input. That includes mocking TouchPanel input:
You can easily simulate the TouchPanel in your unit tests:
var m =new MockInputManager();
m.GetTouchPanel().Press(42, 10.0f, 10.0f);
m.GetTouchPanel().Move(42, 20.0f, 10.0f);
The GUI is now based on the Nuclex.Input library. That will allow me to soon
implement TouchPanel input and make the GUI usable on Windows Phone 7. Note that
you can easily hack Windows Phone 7 support into a project by converting
touch input into mouse input. Due to the modular design of Nuclex.Input, you don’t
have to touch a single line of code, simple create your own IInputCapturer!
The game state manager has undergone a redesign. Existing projects shouldn’t be in
trouble, the redesign gets rid of the GameStateManager reference (you can remember
the Reference yourself if you want your states to initiate a transition themselves).
Pop-up game states similar to XNA’s game state management example are now supported.
Upgraded to NMock 3.0. This is mostly an internal change but it really helps being
refactoring-friendly as my unit tests no longer contain method names hardcoded in
All assemblies in the Nuclex Framework are now signed with a strong name, this no longer
preventing you from signing your own assemblies.
And of course, all issues that were reporting through various channels have been
fixed — excluding two possible problems I can’t yet reproduce, but will mention here
for honesty: the AffineThreadPool might sometimes be skipping a task under heavy load
and there might be a problem in the PrimitiveBatch when it is handed large amounts of
vertices. I couldn’t reproduce these issues and they’re not occurring in my own game,
but if anyone notices such an issue, please contact me!
There are two changes that might have impacted visual quality: XNA 4.0 uses premultiplied
alpha everywhere (whereas XNA 3.1 processed the alpha channel as-is) and, as revealed by
"Krome Studios", The FontDescriptionProcessor in XNA 4.0 generates
a texture with DXT3 (a form of compression that limits each block of 4×4 pixels to contain
only 4 different colors and reduces the alpha channel to 4 bits of precision or 16 levels,
Because I’ve written a custom FontDescriptionProcessor for XNA 4.0 which outputs compatible
SpriteFonts but uses FreeType instead of Windows’ GDI font
API, I decided to do a little comparison.
In all cases, DrawUserPrimitives() was marginally faster than
the DynmicVertexBuffer, but it appeared to be a very bad idea to use
a DynamicVertexBuffer on the Xbox 360. I had a really nice discussion with
Shawn Hargreaves on the XNA forums where he provided a lot of in-depth information about how
things work on the Xbox 360: .
One of today’s threads on
the AppHub forums reminded me if my earlier benchmarks, so I decided to dig out my old benchmark
and redo it in XNA 4.0. The benchmark uses my Nuclex Framework‘s PrimitiveBatch class,
which underwent some changes since then, so I repeated the XNA 3.1 benchmarks in addition to
getting the new data for XNA 4.0.
I just love listening to music in bed, right before going to sleep.
You can close your eyes and focus, experiencing the music like a movie
and less like the background noise music is often degraded to during
the day. After moving my home office to a different floor, however, my
bedroom is no longer close enough to my PC to do this (I used a rather
quirky solution, using a game pad to remote-control WinAmp and later
shut down my PC :D).
This put me on a quest for a replacement. Because I ripped my entire
CD library as FLAC
and stored it on my home server (running Gentoo
Linux and serving the music files as a network share via Samba),
I was looking for a player that supported FLAC and, ideally, would play
music from a standard network share. This is what I ultimately decided on:
I admit that I half expected this category of devices to not exist at
all, because a “normal” person doesn’t have a home server or a PC that’s
always on. And when I found something I expected some half baked showpiece
hardware, but was yet again positively surprised. Read on for my personal
review of this brilliant device!
The new release adds a new library, Nuclex.Input, which is a very lightweight
library that adds seamless support for DirectInput game pads and joysticks,
well-behaving keyboard text input, event-based input and the ability to mock
any kind of input in your unit tests. Instead of firing up your XBox 360
each time, you can now write simple tests that simulate controllers being
attached and detached.
Also new is full support for XNA 4.0 on x86 and XBox 360. Windows Phone 7
is also supported by most of the libraries. The PC builds all target
the .NET Client Profile, allowing you to reduce the footprint of your
installer. Special .NET 4.0 client profile builds of the third-party
libraries (LZMA, NUnit, NMock, log4net and SlimDX).
Of course, all bugs reported since the last release have been fixed!
Proponents of dependency injection try to design classes so they can either
work autonomously or get all services they rely on handed to them through
their constructor. But even without dependency injection, the situation often
arises where certain classes need to interact with a lot of other objects.
In these cases, you often end up with very complicated constructors and
a lot of duplicate code:
Above class takes care of rendering the visual and audible representations
of a RadarBuilding in a computer game. As you can imagine,
the same references will be required by other buildings, think
TankFactoryBuilding, CommandCenterBuilding and so
on – all duplicating the fields, their assignment and the complex constructor.