Developers following my twitter feed may already know that in
the past few days, I’ve been working on a new component for
the Nuclex Framework: Nuclex.Input. This component aims to
solve all problems I ever had with input devices in XNA 🙂
It’s a very simple library that provides input device classes
similar to the ones in XNA (Keyboard,
but instead of 4 game pads, there are 8 (with indexes 5-8 for
DirectInput-based controllers). All input devices
provide events (like KeyPressed and
CharacterEntered on the keyboard or
MouseWheelRotated on the mouse, for example).
Here’s a quick run down of the features:
Well-behaving keyboard text input
Honors keyboard layout and system locale
Supports XBox 360 chat pads
Very easy to use: just subscribe to an event
Support for standard PC game controllers
Works with any DirectInput-compatible controller
Mouse movement with sub-pixel accuracy(postponed)
Finally put those expensive high-dpi mice to use 😉
Allows event-based input handling
Fully type-safe: events instead of message objects
Only compares states if events have subscribers
Mouse and keyboard don’t have to compare states at all
Zero garbage: doesn’t feed the garbage collector
During usage, the library produces zero garbage
Curious? Click on “Read More” to view some code samples!
Last Friday (and I only now notice it was Friday the 13th :D) my screen stopped
working. I dismantled it and found some bad capacitors, then decided to do a small
foto story showing my attempt to get it working again:
My Screen went
Today the electronics components I ordered arrived and I could finally replace
those capacitors I found to be broken last time.
Soldering in the new capacitors was surprisingly easy. I remember that when I
did this in my childhood, I spread solder everywhere except where I wanted it to 😉
In the old design, an IInputReceiver was fed by one of
two classes: one was the XnaInputCapturer which relied
completely on XNA’s input device classes (Keyboard,
to track the status of any input devices, the other was the
WindowInputCapturer which intercepted incoming window
message for XNA’s main window to obtain the status of input devices:
This wasn’t even nearly an ideal solution because now I would have
to copy & paste the game pad polling code from the
XnaInputCapturer to the WindowInputCapturer
if I wanted game pad input on Windows. The new design should fix this,
but still follow the concept of routing all input through a single
interface (IInputReceiver) to allow users to easily
attach the GUI to their own input handling code.
Earlier this year, one of my monitors started behaving strangely
each time it was turned on the first time for the day. The image
would flicker on and off, first very slow, maybe twice a second,
then faster and faster still until it displayed a permanent and
Over time, things got worse. First it would take just a few seconds,
then two months later, the screen would stay black for minutes
before the now familiar flickering started and the display settled.
This morning, the display just remained black.
Some googling revealed the likely cause: bad capacitors. Between
1999 and 2007, many electronic parts were sold with bad capacitors
because, at least that’s a popular story, one Taiwanese company had
obtained the knowledge to build electrolytic capacitors via espionage,
but the informations were incomplete and the electrolyte was missing
and certain agent that prevented the hydrogen from escaping.
Whatever the reason, my TFT’s production date falls into the problematic
range and symptoms are similar to things other people reported. So I
went ahead and tried to take a look at the thing, documenting each step
with my camera.
XNA provides a neat little system for you to organize your
game’s different parts in: GameComponents.
You can use them to modularize your game’s subsystems,
eg. have a GuiComponent, PhysicsComponent,
SceneGraphComponent etc. so you avoid having all that
code in your Game class, or can use them for your actual
game objects in smaller games.
However, the GameComponent and
DrawableGameComponent classes provided
by XNA force you to reference the Game
class. This is unfortunate if you want to use those components
in a WinForms-based XNA application and gets in the way
when you try to write unit tests for your components because
now you have to create a dummy Game
instance as well (and better hope that component won’t
go shopping for references in the Game‘s
Components and Services
collections as well).
The first thing I did was, of course, to adapt SunBurn to Ninject, a very tidy
dependency injector that works on the XBox 360 and even on Windows Phone 7,
into the SunBurn example application. This article gives a short overview about
the overall structure and provides you with an example application if you want to
give Ninject a try yourself.
Whenever I needed a screenshot of some application for this website, I used
an image editor to cut out the window’s drop shadow, generated an alpha channel
from its luminance, added that as a layer behind the actual application window
and saved the entire thing again.
Today I wrote a small utility to automate this process for me: AeroCapture.
Pressing the “Print Screen” key will take a screenshot of the active window,
and save it as a .png in the My Pictures directory, retaining
the window’s drop shadow in the image’s alpha channel.
You can download it here:
[rokdownload menuitem=”17″ downloaditem=”42″ direct_download=”true”]AeroCapture.7z[/rokdownload]
(C# source code included)
This got me thinking. Somehow, whenever I have the choice between…
spending 2 minutes doing a repetitive task that I’ve done a few dozen times
before already (like fixing up the screenshot for my website)
or spending 4 hours to automate the task
…I always choose the 2 minutes approach. I can continue working on what I was
planning to do and I don’t have as many utilities to maintain.
I’m very excited about .NET 4.0 because this is the first standalone
release of .NET since 2.0 came out, meaning that it doesn’t bundle
any of the older runtimes. As you may know, .NET 3.5 is actually just
.NET 2.0 with some more assemblies – all the magic required for
LINQ, extension methods and lambda expressions happens in the
The new Visual Studio UI also looks very nice and the darker
background puts the actual work (the code) into focus. But there
have been some changes like the apparent removal of the
Debug/Release combo in the toolbar and the ability to add your own
External Tools to the Tools menu in the Express Editions (don’t
worry, both are still there, I explain how to enable them a bit down
in this article).
So I decided to write a small heads-up on why I think Visual Studio
2010 and .NET 4.0 are cool and how to get back your favorite options
if you’re already used to the Visual Studio 2008 Express Editions.
Being an adherent of Continuous
Integration, I need a build machine that runs round the clock even
when my workstation is turned off. As I’m running a small home server,
this wouldn’t be an issue — if it weren’t for the fact that my home
server runs Linux and 99% of my development happens in Windows. So I use
virtualization to run a small Windows system on top of my home server.
In the past I used VMware
for this job. VMware worked well for me and performance was quite good,
but now that I’ve switched to a fully headless system, I noticed that
package pulls in most of the X11 libraries –
which I’m not particularly keen on having on my system due to their
So I went shopping for some alternatives. KVM
sounded interesting (and was the leanest virtualization solution
I could find), but the Gentoo Wiki stated that Windows didn’t work
in qemu with recent kernels, so I went looking on – and found
VirtualBox. This article
explains how to set up VirtualBox on a headless Gentoo system.
If you haven’t heard of Continuous
Integration yet, it’s the practice of setting up an automated system
that rebuilds projects automatically whenever someone commits a new change
to your source code repository. It ensures that whatever is in your
repository builds and runs: automated builds usually involve compiling,
running unit tests and packaging the installer.
To do continuous integration, you need a tool that monitors your source code
repository and starts the builds – a continuous integration server. My weapon
of choice is TeamCity, a free CI server
written in Java with first-class support for .NET and its toolchain
(like NAnt, NUnit,
NCover or PartCover).
TeamCity is pretty easy to deploy – the Windows package has an installer
which leaves you with a fully working server after just a few clicks and even
the Linux package is pretty simple to deploy: Download, unzip, run
runAll.sh and you’re done. To properly integrate it into a Linux
server (so it will come back up after rebooting and can be reached via HTTP
without having to run either Apache or TeamCity on a non-standard port),
you’ll need to run your own Tomcat server.