Category: Game Programming

My coworker Rick has taken the time to write out his thoughts on the infamous render loop.  Naturally, he needed to do this for his upcoming book, but it’s something we here have been talking about for a long time and I simply haven’t had the time to look at very indepth..

He’s bounced some ideas off of me periodically for the last few weeks, and I think the solution he came up with looks pretty solid.. I haven’t played with it much (ok, not at all), but will do so soon..

Jason Olson recently conducted an interview with me about various Managed DirectX topics..  I imagine some people might enjoy that kind of stuff.

Oh, and also, before anyone asks, I don’t expect to agree to anymore interviews in the short term.  =)

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
}
}
}

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 file if you’re using the functionality provided there)

Like Mitch mentions, I’ll be giving a talk at Meltdown this week (both Tuesday and Wednesday) on using Managed Code in gaming.  For those of you who won’t be attending the conference, the talk’s slides will most likely be posted on MSDN shortly after the conference is over.

It will be a good time.