Games – Page 2 – Nuclex Games Blog

Nuclex Framework R1404 Released!

March 17, 2011February 21, 2012 Cygon

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);
m.GetTouchPanel().Release(42);

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

Comparison of SpriteFont rendering quality

XNA Sprite Font Quality

December 9, 2010February 21, 2012 Cygon

Screenshot of fonts in XNA 3.1, XNA 4.0 and the Nuclex font processor There has been a discussion on the XNA forums regarding a slight decrease in the visual quality of SpriteFonts from XNA 3.1 to XNA 4.0: XNA 4.0 renders SpriteFont differently (and not for the better).

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, see Wikipedia).

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.

Chart showing the PrimitiveBatch benchmark results in XNA 4.0, clipped to 500 FPS

DynamicVertexBuffer versus DrawUserPrimitives, Round 2

November 6, 2010February 21, 2012 Cygon

More than a year ago, I did some benchmarking in XNA 3.1, comparing the vertex throughput I could achieve on my GeForce 8800 via XNA’s DynamicVertexBuffer class versus just calling GraphicsDevice.DrawUserPrimitives(). Here’s my earlier benchmark: Efficiently Rendering Dynamic Vertices.

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.

Nuclex Framework R1242 Released!

October 2, 2010February 21, 2012 Cygon

There’s a new release of the Nuclex Framework available on CodePlex!

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!

MVC in Games

September 13, 2010March 10, 2012 Cygon

In the game I’m currently working on, it appears that I’m slowly drifting towards a design that’s a close resemblance of the Model-View-Controller (MVC) pattern, despite originally rejecting the idea because I believed it would require my game world to expose too much of its internal data just so the view could keep track of things.

Because I originally believed to be building a very simple game with very simple logic, I chose a design that would create a nice, non-fractured interface to the world so I would have an easier time building the AI and player controls on top of it:

UML diagram showing an object tree representing the entire game state

In this design, everything could access everything else – a monolithic world component where the public interface was well encapsulated, but that allowed the implementation to take the most direct path possible.

"Everything could access everything else" doesn’t mean my objects directly modified each other’s state, but it meant, for example, that a building had a reference to the island it was placed on and that it could call an internal method in the Island class to inform it when the building was destroyed or moved.

A full design, in contrast, would give the buildings an interface through which they determined properties about the ground (is it too rough? underwater?) and some events so its owner would know when the building was destroyed.

If I had only taken game logic into account, this all would have worked out very well. But there were some things that added a lot of complexity…

Input Mocking in XNA

September 2, 2010February 22, 2012 Cygon

I have updated my input library to a level where I think I can release it into the Nuclex Framework now. The design was tailored to make the input manager mockable (replaceable with a dummy object for unit testing), but the effort of mocking the entire input manager (versus just one input device) on an ad hoc basis was a bit too high (or too unreadable when using a dynamic mock object library).

So the final revision has mocked input devices and a matching input manager built in:

UML diagram showing the IInputService implemented by a real and a mock manager

New Component: Nuclex.Input

August 23, 2010March 10, 2013 Cygon

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, Mouse, GamePad), 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!

Download

This component will be in the next release of the Nuclex Framework!
If you want it now: Nightly builds, Source code (svn)

Quo Vadis, Input System?

August 17, 2010February 20, 2012 Cygon

I’ve spent some time thinking about how input is handled by my GUI library. One issue I didn’t cover in its initial design is that people might want to use the GUI library at the same time as their game is running (think of a command palette in a strategy game). I’ve already got some requests on the CodePlex forums (How to determine if a screen-position (i.e. mouseclick) is on any gui-control ? and Unfocusing from GUI) and it’s about time I did something about this.

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, Mouse, GamePad) 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:

UML diagram showing the input system with two distinct classes for XBox and Windows input

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.

To GameComponent or not to GameComponent

August 13, 2010March 12, 2012 Cygon

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

UML class diagram of the GameComponent and DrawableGameComponent classes

Luckily, the GameComponentCollection used by XNA to store your components manages IGameComponents and updating/drawing are based on the IUpdateable and IDrawable interfaces alone, so there’s nothing preventing you from rolling your own components without referencing the Game class.

Using Ninject with SunBurn

August 11, 2010January 4, 2013 Cygon

First, let me say sorry if I seemed to be absent for the past months. I was quite burned out and didn’t want to do much with computers during that time :).

My “XNA Game Architecture” series was left hanging, and right when it got interesting, too. I’ll try to find the time to continue where I left off. For now, here’s a small appetizer:

Some weeks ago, Synapse Gaming offered their SunBurn Lighting and Rendering Engine for half the price. This was too good an offer to pass and so I now find myself being able to do much better lighting effects than I had ever hoped to achieve in my game.

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.