Programming – Page 5 – Nuclex Games Blog

Nuclex Framework R984 Released!

December 3, 2009February 21, 2012 Cygon

I just uploaded a new release of the Nuclex Framework on CodePlex!

It has been a lot of work getting the GUI library finalized. For once, I really wanted to have 100% unit test coverage on the whole library, which meant a lot of work ensuring the design allowed for this and thinking of all the test cases. But hey, what other GUI library can provide that level of unit tests! :)

Another feature I didn’t want to let go of was control navigation with the game pad and cursor keys. The idea is that you, the developer, just throw some controls on the screen and the GUI will automatically figure out which control to change focus to when the player uses the thumb stick on his game pad. This means you can just add four buttons labeled “New Game”, “Options”, “Credits” and “Quit” to your screen and voilà, you’ve got a main menu the user can interact with using his mouse, keyboard or game pad.

WiX XNA Installer 3.1

October 21, 2009February 21, 2012 Cygon

I just uploaded a new release of my WiX XNA Installer template that has been updated to XNA 3.1!

If you happen to have a customized installer built on the XNA 3.0 template, fear not, for the required changes are very small! Use your favorite Diff/Merge tool and copy over any changes referring to Xna_3_1 into your existing installer.

I have declared this release a beta because I haven’t gotten around to testing it on all possible operating systems.

Nuclex Framework on CodePlex

September 21, 2009February 21, 2012 Cygon

The Nuclex Framework has been released to CodePlex today!

Instead of only writing about all the cool stuff and then pointing people at my Subversion repository whenever someone asks for the source code, I finally sat down and published the entire Nuclex Framework on CodePlex, together with lots of examples, documentation and screen shots.

The Nuclex Framework consists of small isolated building blocks that you can pick from, so you can easily use just the things you require and ignore the rest (or even create your own trimmed-down edition of the framework if you’re not worried about doing it all again when a new version is out).

All the highlights I wrote about in this blog (and quite a lot that I didn’t write about) are neatly organized in there. And the code’s quality should hopefully speak for itself :)

Just to list some of the more interesting things, there’s a Deque collection (faster than List<> and LinkedList<> and much less garbage), 3D vector font rendering code, 7-Zip content compression, a 3D SpriteBatch equivalent, rectangle packing algorithms for texture atlas creation, a flexible multi-threaded particle system, a work-in-progress GUI library with skin support, a cleaner game state management system, a debug overlay renderer and some helpers that allow you to automatically create VertexDeclarations from a structure without listing the VertexElements by hand.

So what are you waiting for, check it out! :D

Efficiently Rendering Dynamic Vertices

July 27, 2009February 21, 2012 Cygon

Sometimes, games have to render highly dynamic geometry such as sparks, bullet trails, muzzle flashes and lightning arcs. Sometimes it’s possible to off-load the work of simulating these things to the GPU, but there are effects than can’t be done by the GPU alone.

These cases usually occur when effects require heavy interaction with level geometry or when they require lots of conditionals to mutate a persistent effect state. And sometimes, the effort of simulating an effect on the GPU is just not worth the results. If you have maybe a hundred instances of a bullet trail at once, letting the GPU orient the constrained billboards for the trails instead of generating the vertices on the CPU might just not yield any tangible benefits.

However, there are still a lot of traps you can run into. A typical mistake of the unknowing developer is to render the primitives one-by-one either using one Draw[Indexed]UserPrimitives() call per spark/trail/arc.

This is not a good idea because modern GPUs are optimized for rendering large numbers of polygons at once. When you call Draw[Indexed]UserPrimitives(), XNA will call into Direct3D, which will cause a call into driver (which means a call from code running in user mode to code running in kernel mode, which is especially slow). Then the vertices are added to the GPU’s processing queue.

By sending single primitives to the GPU, this per-call overhead is multiplied and can become a real bottleneck. To demonstrate the effects of making lots of small drawing calls, I wrote a small benchmark and measured the results on my GeForce 8800 GTS 512 and on whatever the XBox 360 uses as its GPU.

Chart showing a drastic performance bottleneck for excessive DrawPrimitive() calls

WiX XNA Installer 3.0

April 19, 2009February 21, 2012 Cygon

This past week I’ve been working on my WiX XNA installer template again because I really wanted to integrate installer generation into my continuous integration builds. That way, I can hand test versions to friends without explaining in detail how to get it to run and it’s one less worry I have when I release the game.

After some FAQ reading and some questions on the XNA Forums, I had the certainty that XNA 3.0 can be deployed with .NET 2.0 only (if you change your project configurations to target .NET 2.0). This is good news because the .NET 3.5 installer is huge and, on a fresh system, I’ve had about a 1 in 10 success quote of the installer finishing without an error, so my trust in the .NET 3.5 installer is completely shattered.

Screenshot of an installer showing that DirectX 9.0c and XNA 3.0 are installed

Island War Day 7

March 9, 2009February 19, 2012 Cygon

Today, I’ve got some new screen shots! Read on :-)

Over the weekend, I implemented proper camera and terrain selection controls. Getting keyboard, mouse and gamepad working at the same time proved a bit of a nightmare. PC RTS players will expect the arrow keys to move around their view and the mouse to be usable as a selection tool. XBox 360 RTS players need some way of telling the game where to place buildings, but the gamepad isn’t suited for this task as well as the mouse is.

So I decided to split my terrain into a regular grid in which a terrain cursor can be moved. The grid is in units of 3×3 terrain quads, which allows me to add some detail to the terrain on the sub-grid-cell level. Otherwise, it would look fairly obvious to the player that the terrain is based on a heightmap with regular X/Y samples.

Screenshot of an island with flak buildings intercepting an incoming missile

Island War Day 6

March 6, 2009February 18, 2012 Cygon

During the past week, I got missiles working to a point where they will launch, gain altitude, head towards their target and dive for the attack. They will damage the island (which means scraping off texture layers and possibly alter the terrain, not sure whether I want this, however). Buildings in the vicinity are then destroyed.

For the missile trajectory, I went for the simplest thing that could possibly work:

Until the missile has reached its cruise altitude, it will ascend at a 45 degree angle. If during this phase, missile closes in to the target so much that it needs to start diving, the diving phase will be entered.
Once at its cruise altitude, the missile will simply fly in a horizontal line towards its target. If the missile gets closes enough to its target, it will enter the diving phase.
In the diving phase, the missile accelerates to maximum speed and descends towards its target at a 45 degree angle. Once it hits the ground, it explodes.

Why Beginners Should Start with XNA

March 4, 2009February 18, 2012 Cygon

Today, I watched an interesting discussion on gamedev.net where someone asked why everyone is recommending beginners to start off with XNA and C# whereas the entire gaming industry is based on C/C++.

I would have expected to read something along the lines of

“We recommend XNA because it’s very easy to learn and you will hit the ground running fast. It teaches beginners the kind of thinking required to lay out the logic of a program and doesn’t discourage them by forcing them to write boring console applications for months until they know the semantics of the language well enough to use a graphics library such as SDL, DirectX or OpenGL. Some people may not even want to enter the industry, so C# and XNA is a fine choice for them. Those that do can switch over to C/C++ after they’re fluent in C# and it will be a mostly easy going, incremental learning process.”

Instead, an ugly mess resulted with people firmly stating that .NET/Mono is the way to go for games, that the gaming industry is using it for prototyping, scripting and development tools and that the only reasons for not adopting C# yet are legacy code bases and unwillingness by developers to learn new stuff or to change proven ways. People began dissecting each other’s posts one by one and, well, if you’ve been on the internet some time, you can probably imagine how it turns out.

Island War Day 5

February 4, 2009February 18, 2012 Cygon

Last time, I wrote about how I set sail for the Island War project and how my motivation faltered slowly over time. And I promised to write a follow-up post that explains how I believe to get back on track and finish development of my Island War project. Well, here it is, folks!

I see the primary reason for my loss of motivation in my tendency to write and fully implement systems instead of just the piece of code I need. While I knew that I had to “write a game, not an engine”, I still fell for the same old trap: I didn’t technically write an engine, but I started to design entire systems and fully implement them when all I needed was a small routine to get the job done.

Island War Day 4

January 22, 2009February 18, 2012 Cygon

It’s baack!

Slowly, the Island War project begins to grind its wheels again. Time for a review of what’s happened so far. When I started this project, I was still intoxicated from the successful completion of my just-for-fun project “Ball Race”. I was eager to build a real, full-blown game taking no shortcuts and doing everything in the best way imaginable.

This turned out to be a real time waster and motivation sapper.