The first Managed DirectX game..

To my knowledge, the first ‘retail’ game written in Managed DirectX has been released..  It’s called “Tin Soliders: Alexander the Great“, and you can read more about it here.  It seems to be a turned based strategy game.  I’ve never played it, I really don’t know anything about it, but I expect it to be the first of many games written entirely in managed code using Managed DirectX..

Oh, and if there are other ‘retail’ games written in MDX that I’m not aware of, sorry..  You should let me know!

The DirectX SDK – Even quicker updates..

You may not be aware, but the DirectX SDK is moving towards a more flexible (and quicker) release schedule..  With that, our next release is now live.  Here are a few quick details:

Tool Updates
PIX             – Call capture and playback, Asynchronous events, Triggers and Actions
Maya Exporter   – Maya 6 Support, Procedural texture support, Updated installer

New Samples
C++             – AntiAliasing, Instancing, ConfigSystem
Managed         – PrtPerVertex, FragmentLinker , SimpleAnimation

Bug fixes
D3DX            – Debug Output Muting, PRT Blocker meshes no longer have a 65,535 vertex limit, texture UV coordinate transformation)
DirectX for Managed Code        – memory leak in TextureLoader.FromFile, unhandled exception errors)

Here are the links to the downloads.

Release Notes
http://www.microsoft.com/downloads/details.aspx?FamilyId=97CDCC31-7D0C-4F4F-81B1-16A0A7C29FB9&displaylang=en

Software Developer Kit
http://www.microsoft.com/downloads/details.aspx?FamilyId=B7BC31FA-2DF1-44FD-95A4-C2555446AED4&displaylang=en

Extras
http://www.microsoft.com/downloads/details.aspx?FamilyId=D6F237DE-A6EE-4DED-8BB6-139536162EB8&displaylang=en

Symbols
http://www.microsoft.com/downloads/details.aspx?FamilyId=87336CEE-864D-440E-840F-25C53D5DEEE4&displaylang=en

Writing a game using Managed DirectX.. The Contest..

With the upcoming release of my new book, I thought it would be pretty cool if there was a contest held for writing the ‘best game’ using Managed DX.  Details are sketchy right now (like will people outside of the US be allowed to enter), but it’s something that will be happening..

While rules and regulations are still being decided, here are some things you can start thinking about if you’re interested..  The devleopment process will probably be two-three months..  Entries will be scored on numerous different ‘categories’ such as:

  • Originality
  • Gameplay
  • Fun-Factor
  • Use of Shaders (HLSL)
  • Use of ‘DX9 Features’ (i.e., PRT, HDR, etc)
  • Artisitic appeal

Naturally, the categories will be weighted.. Oh, and good prizes, etc..  I’ll keep you posted on details as they become available..

Why can’t I compile Managed DX code using the MC++ Compiler?

This has become a popular quest recently, so naturally that means it must be time to blog about it..  People have been discovering that simple MDX code just doesn’t seem to compile with the Summer 2004 release of the Managed DX assemblies..  Simple code such as this:

Form1 __gc* pForm = new Form1();
// Create a new device
Device __gc* pDevice = NULL;
PresentParameters __gc* pParams = new PresentParameters();
PresentParameters* pArrayParams __gc[] = {pParams};
// Setup params
pParams->SwapEffect = SwapEffect::Discard;
pParams->Windowed = true;
pDevice = new Device(0, DeviceType::Hardware, pForm, CreateFlags::SoftwareVertexProcessing, pArrayParams);

They’ll see compilation errors such as:

Form1.cpp(24) : error C3635: ‘Microsoft.DirectX.PrivateImplementationDetails::IDirect3DDevice9’: undefined native type used in ‘Microsoft::DirectX::Direct3D::Device’; imported native types must be defined in the importing source code
did you forget to include a header file?

Which is puzzling to say the least, and even more so because using the Summer 2003 SDK release will work correctly.  The problem lies in how the MC++ compiler generates assemblies with native code in them.  First, it will actually create public variations of the unmanaged components (i.e., IDirect3DDevice9) and stick them in the assembly.  Unfortunately, it places these ‘types’ in whatever namespace the #include for the header file happened to be in, normally the ‘blank’ namespace.  Look at the MDX assemblies from the 2003 release in the object browser and you’ll see what I mean as it is literally cluttered with hundreds of these bogus types.

For the 2004 release, we decided to ‘tidy up’ these references, and move them into a single ‘private’ namespace.  Looking at the MDX assemblies for the 2004 release, you’ll see that all of those unusable ‘types’ are now found in the Microsoft.DirectX.PrivateImplementationDetails namespace.  Much cleaner to look at, much better organized.

However, now when the MC++ compiler tries to *use* these assemblies, for whatever reason it looks for the native types to be declared *within that same namespace*.  You’d have to ask the MC++ team why this is since it seems a little strange to me (i.e., C# and VB.NET work just fine without this information)..  In order to successfully compile the code above using the 2004 release you need to actually *include* the d3d9 header files within the namespace mentioned above.  Something such as:

namespace Microsoft
{
namespace DirectX
{
namespace PrivateImplementationDetails
{
#include <d3d9.h>
}
}
}

Thankfully, the MC++ compiler for the Whidbey timeframe is much improved, and situations like this will soon be a thing of the past.  But in the meantime, this is how you get around the issue people are having trouble with.  (Note that you’d also need to include the <d3dx9.h> file if you’re using the functionality provided there)