GDCE Day 1: XNA Tutorial day

Introduction

Ever since Microsoft announced the development of the XNA technology, there have been rumours flying around the net about exactly what it means for game development. The first day of GDCE was supposedly devoted to a series of lectures on XNA technology and about where Microsoft is going with XNA and DirectX, and their Windows and XBox platforms.

Essentially, XNA aims to do away with all the tedious platform specific boilerplate code that gets reinvented every game by providing a basic game framework that does it all for you. There are a number of advantages to this, for example the game's interaction with the OS can be standardized and thoroughly bug tested. Alt Tabbing in Windows for example, will be handled silently within this framework, resulting in less work for the developer and fewer bugs in the game. (No more crashing to the desktop when you accidentally hit the windows key…) This exposes a common interface to the developers, meaning that a porting from PC to XBox or vice versa should be an even simpler affair.

Currently, the only platforms Microsoft are aiming to develop these frameworks for are Windows, XBox, and Mobile platforms. However, they have no intention of stopping third party developers from developing frameworks for additional platforms such as the Sony Playstation 2 and Nintendo Gamecube consoles, which would further increase the portability of games developed with this technology.

The first step in Microsoft's convergence towards the XNA platform is to port some of the powerful tools developed for the XBox to Windows, and much of the event was devoted to discussing these tools. XBox programmers may want to skip a few paragraphs, as they'll be familiar with technologies such as PIX and XACT already.

XACT

The first tool on the agenda was XACT. (XBox Audio Creation Tool) XBox developers will already be familiar with this technology, but as part of Microsoft's convergence towards XNA, this tool is being ported to Windows. Essentially, this tool allows sound engineers to design parameterised sound patterns, which will cross fade, mix and match sound effects automatically based on a few variables. A racing game was used to demonstrate the power of this tool. A different engine noise was used for each gear, and parameterised so that simply by changing a single variable representing the rpm of the engine, the sound effect would change in pitch in a controlled manner. Then, at a certain number of revs, automatically switch to the next gear, and so on. All this would be set up by the sound engineer, and could be tested without the need for a working game engine. All the programmer needs to worry about is passing the 'revs per minute' variable to the sound engine. The system is highly configurable, and can cope with a wide number of effects, any or all of which can be parameterised or randomised. The result is that you can create interesting, non-repetitive sound effects or music with only a handful of actual sound files.

PIX

Next up was PIX, the graphics pipeline profiling tool. Again, this tool is already available for the XBox, but is now being ported to Windows in order to help developers get the most out of their graphics engines. This tool allows you to set a wide range of counters, covering DX calls, and maybe even driver specific calls if you have a suitable plugin to do so. The logged information can be inspected in great detail, allowing you to view a series of frames, a single frame in detail, or even individual calls within a frame. It also allows you to view a great deal of information about the rendered image, showing overdraw, z buffer state, or even the complete history of a given pixel. This tool should make it possible to efficiently optimise the graphics pipeline, rather than relying on guesswork as to where the problems lie.

Unfortunately, the Windows driver model makes a full port of PIX impossible, so for the time being at least, the Windows port will only have a subset of the functionality of the XBox version. However with the revisions to the driver model proposed for Longhorn, a more complete version should become possible.

Common Preview Pipeline

The common preview pipeline is another tool aimed at content creation. As the use of shaders increases in games, artists face the problem of not being able to see what their creations will look like in the game once the shaders have been applied. Furthermore, they are often reliant on the programmers to tweak the shaders, which slows down their productivity and makes it harder to get the best results.

The common preview pipeline consists is a set of plugins for the common tools such as Maya and 3DSMax, which puts one of the viewports into a special preview mode, which allows the artists to view the effects of shaders in real time. Perhaps most importantly of all, the shaders can contain embedded parameterisation (known as 'Annotations') information that can be parsed by the plugin and shows up as a series of UI controls. These controls allow the artist to tweak various elements of the shader, such as colour, or frequency etc, within the constraints set by the shader programmer.

HLSL

Several of the lectures dealt with various enhancements that have been made to the HLSL in the latest version of DirectX. For example, the addition of Annotations and Semantics, which are designed to give hints to the application about how an HLSL variable should be used. For example, Semantics allow you to denote unambiguously that a particular variable should be filled with the world transformation matrix, or perhaps a random number, or the elapsed time. Annotations allow you to define UI information about a variable, so that variable can be tweaked by an application such as the Common Preview Pipeline plugin mentioned earlier. Other tricks included the use of preshaders to drastically reduce the amount of code that needs to be executed in a shader, by performing all the set up and preparation code in the preshader.

The Future of DirectX

The day closed with a session on the direction Microsoft is planning to take with the DirectX API and Windows.

It seems that the various components of DirectX are set to go their separate ways, as the new XNA tools supersede them. DirectPlay is unlikely to change from its current incarnation, but the addition of the XBox Live tools will more or less replace it. DirectSound and DirectMusic will be effectively replaced by the XACT interface. More changes are in store for Direct3D, which will be replaced by WGF (Windows Graphics Foundation) and will be upgraded on a regular basis so as to remain in step with technology. This splitting up of DirectX makes a certain amount of sense - some technologies change more frequently than others, and it makes little sense to download a huge SDK containing everything just because one element has changed.

WGF should see the end of much of the fixed function pipeline - vertex lighting, fog, alpha testing, FVFs, triangle fans and point sprites are all being chopped. Vertex and Pixel shaders will become more closely connected in the Common Shader Core. If Microsoft have their way, it will also bring the end of Device Caps. IHVs will be more or less forced to meet a minimum set of requirements for WGF compliance. This is a rather contentious issue of course - the IHVs often compete with each other on features as well as raw speed. This could mean that while WGF should give developers a good, powerful and importantly, consistent set of features to work with, developers who are prepared to go the extra mile with a more flexible API may be able to take advantage of extra features that different cards may provide.

Another key feature of WGF is stability. With the introduction of Longhorn, the whole desktop will be hardware accelerated, making it essential that the graphics pipeline is stable. The new driver architecture for Longhorn will help in this regard, by bringing some of the driver processing out of the kernel and into user mode, making it easier to recover from horrible bugs. Microsoft are hoping to completely do away with BSODs caused by driver problems, instead handling such errors in a rather more graceful manner.

New features include improved state management, high-definition rendering formats e.g for high dynamic range lighting, normal map compression and the addition of texture compare filters. They are also planning to add a new element to the graphics pipeline for processing more complex geometry, which may in turn lead to the use of the GPU for non-traditional tasks, such as collision detection or physics.

Summary

In conclusion, Microsoft stressed very strongly that the XNA platform and related tools are aimed entirely at developers. They want to deliver powerful tools that will make development more efficient without compromising quality or creativity. It's very important to them that these tools offer all the features that developers want, and therefore they want as much feedback from developers as they can get. They emphasised the importance of signing up to the beta programs and getting as many developers as possible to make sure that they can meet our requirements.

Day 2