Category: Managed DirectX

A cornucopia of topics!

It’s been a while since I’ve written anything here, but a few other posts today have gotten me to change that now.  First David Weller tries answering the question “Does Managed DirectX discriminate against VB.NET Developers”..  Since he put me on the spot to answer it, i’ll do that first.

In short, no, of course not.  He hits the nail on the head that it’s mainly about time, and given my busy schedule, it’s quite difficult to get the stuff out that I do end up releasing.  It’s also at least partially about maintenance.  Considering in the past when we had VB.NET and C# version of the samples, the VB.NET versions were simply mirrors of the C# version.  Which means not only do you need to ‘write’ two versions of the same code (3 if you count the original unmanaged version), whenever any one of them changes, all of them must be updated..  It can become quite a bit of work when the samples are changing daily.

I’d also disagree with David’s assertion that you can’t possibly master DX without knowing C++, but the fact is the *majority* of our customers (the game developers) do know c++, C# is a more logical language to use as the starting block for the managed samples.  We will have a VB.NET sample in this upcoming release though.  Oh, and the original post that David quotes is using a bug that shipped in the summer 2004 release as the reason for the discrimination question..  It is just that, a bug.  One that has now been fixed and will be released soon.  We would *never* intentionally ‘break’ something out of spite or whatever the case may be.

So, to summarize, we have no intentional ‘discrimination’ against vb developers in the least.  In a perfect world, where I had infinite time, we would have thousands of samples, in all the languages available, but the fact is, it’s not a perfect world.  We’re trying to add new stuff (including VB samples) as we’re progressing.

David also mentioned Andy Dunn’s new web site on Managed DirectX.  It includes an interview with the lead developer on the first retail MDX game i posted about last time.  In his ‘disadvantages’ section, he lists a few problems he had with MDX, which were all based on the Summer 2003 version.  I believe that I addressed all of those in the latest version, but by all means, if people are seeing bugs and/or issues in the assemblies, please let me know.

Since i’m on a writing roll, let’s continue on to books..  The second book should be hitting store shelves ‘soon’ (it’s definitely already been sent to printing, i’m just not exactly sure when it’ll arrive on shelves).  However, the third book is a different story.  At this point in time, I simply do not have the time required to dedicate myself to writing that book.  I think it’s an important book that is written though, so I’m glad that one of my coworkers has picked up the project.  While it may be not be me writing the book or the code directly, I will be at least tangentally involved (he’s right down the hall from me after all).  The project has been left in good hands, and i’m excited to see the end result.

Oh, and unlike David, I haven’t found Half Life 2 to be all that great.  Sure, the graphics engine is *amazing*, but in reality, I’m so burnt out on first person shooters, I just get annoyed with the gameplay half the time..  I fully expect to get flamed for those last two sentences. =)  It would be hard to disagree with the statement on World of Warcraft though.  I find myself playing that way too often..  (Even though I was sad when they deleted my level 60 warlock from the closed beta)

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

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)

The Summer 2004 SDK Update For DirectX has been released..

— Official announcement – DX Web site should be updated soon..
The DirectX(r) Team is pleased to announce the final release of DirectX 9.0 SDK Update (Summer 2004)!
The DirectX 9.0 SDK Update (Summer 2004) contains updated versions of the D3DX library, graphics samples, sample framework, tools and Managed DirectX documentation. Areas of concentration in the DirectX 9.0 SDK Update (Summer 2004) release are:
– HLSL support for Pixel Shader & Vertex Shader 3.0
– Effects Framework performance improvements
– Pre computed Radiance Transfer improvements
– New Sample framework
– New & Updated Samples
– Improved Documentation
– PIX tool for better debugging of Direct3D applications
– Introduction of the Preview Pipeline for easier content creation
For information on what is supported in shader model 3.0, refer to the updated reference documentation. You can install the final releases from the below locations.
Software Developer Kit (230Mb+)
Extras (40Mb+)
Symbols (20Mb+)
Release NotesPlease feel free to post any concerns and/or discuss any issues with this SDK release within this forum, the public newsgroups or mail us directly at directx@microsoft.com
Enjoy!

Why are these textures taking up so much memory..

Someone on the newsgroups was recently asking why loading his simple 800×600 texture was taking up so much memory (more than 5 megs).  He was using code something like the following:

Texture myTexture = TextureLoader.FromFile(myDevice, somePath);

The quest seemed interesting enough for me to post my response here as well as in the newsgroup since this reinforces my belief that you should always know what the methods you’re calling ‘cost’.  It wouldn’t surprise me to find out that most people don’t realize all the things that go in with that simple line above.

So here was my response:

First, if you’re texture is really 800×600, using this overload (TextureLoader.FromFile) will ‘upscale’ the texture so that it is square and a power of two, in this case, 1024×1024..  Assuming 32bit color for each pixel, the default mip level would be:
1024x1024x4 = 4 megs of pixel data.
Now, this overload would also create a mipmap chain down to 1×1, so you would also have:
512x512x4 = 1 meg of pixel data
256x256x4 = 256k of pixel data
128x128x4 = 64k of pixel data
64x64x4 = 16k of pixel data
32x32x4 = 4k of pixel data
16x16x4 = 1k of pixel data
8x8x4 = 256 bytes of pixel data
4x4x4 = 64 bytes of pixel data
2x2x4 = 16 bytes of pixel data
1x1x4 = 4 bytes of pixel data
So, add it all up, and each texture you load would take (on average) 5.6 megs of pixel data..  So the numbers make sense to me..

Now that the Whidbey Beta is out, what about Managed DirectX?

With the release of the Whidbey (err, I mean Visual Studio.NET 2005) beta a few weeks ago, my thoughts have drifted towards how Managed DirectX may work in this new release.  For those of you who haven’t seen VS2005, or the new CLR, the changes there are magnificent.  Across the board, improvements have been made, and the thing is looking wonderful.

So my thoughts roll over to MDX, and I think to myself, “Self: wouldn’t it be awesome if we took advantage of some of those features?”  Who wouldn’t want to declare the vertex data they’re about to use like:

VertexBuffer vb = null;
IndexBuffer ib = null;

Of course that just scratches the surface of the possibilities that would lie in a VS2005 specific version of Managed DirectX.  Which begs the question, what do you think?