So I have some .Net 1.1 code that was using MDX, and everything was cool. I've been trying to get the code to run under .Net 2.0. Everything is compiling fine, but I am getting a LoaderLock error, that I do not get under .Net 1.1. The Error:

Quote: LoaderLock was detected Message: DLL 'C:\WINDOWS\assembly\GAC\Microsoft.DirectX.Direct3D\1.0.2902.0__31bf3856ad364e35\Microsoft.DirectX.Direct3D.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

So naturally I followed the suggested help link. Quoth MSDN:

Quote: Managed debugging assistants (MDAs) are debugging aids that work in conjunction with the common language runtime (CLR) to provide information on runtime state. The assistants generate informational messages about runtime events that you cannot otherwise trap. You can use MDAs to isolate hard-to-find application bugs that occur when transitioning between managed and unmanaged code. You can enable or disable all MDAs by adding a key to the Windows registry or by setting an environment variable. You can enable specific MDAs by using application configuration settings. You can set additional configuration settings for some individual MDAs in the application's configuration file. Because these configuration files are parsed when the runtime is loaded, you must enable the MDA before the managed application starts. You cannot enable it for applications that have already started.

That pages suggests that you can turn off the MDA but That seems like an easyout, and it doesn't resolve what actually caused the error in the first place. So Carrying on. From that page, there is yet another link about the LoaderLock.

Quote: The LoaderLock managed debugging assistant (MDA) detects attempts to execute managed code on a thread that holds the Microsoft Windows operating system loader lock. Any such execution is illegal because it can lead to deadlocks and to use of DLLs before they have been initialized by the operating system's loader.

The resolution on that page doesn't actually suggest how to fix the problem. It says "You will probably see a DLL's DllMain or equivalent entry point on the stack.", but doesn't say what needs to change. So Time for [google]. From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=114707&SiteID=1 "This is a known issue when using the MDX 1.1 assemblies against .Net 2.0." Ah Ha! So I'll just update my references to point to the 2.0 MDX files. But its not that simple. So now I have to replace some code. I suppose I'll have to follow up with additional posts as I resolve each of the things that need to be resolved.

You should either switch to XNA (which is still beta) or stick with MDX 1.1. You can't use the MDX 2.0 files anymore, because they've been timebombed. I've been using MDX 1.1 quite a bit, and never had any deadlock problems.

The LoaderLock exception is something that only comes up when you are running your app inside the Visual Studio debugger. You can turn it off on a per-project basis by going to Debug->Exceptions->Managed Debug Assistants->Uncheck Loader Lock (you should notice that several of them are off by default).

Since Starting this thread I have been looking into XNA. I'm a little annoyed because I prefer to work in VB.Net and they don't want you to XNA in anything but C# at the moment. I ended up downloading C# Express and XNA Game Studio Express Beta 1 and installed both. I was then able to referece the XNA Framework assembly in a test VB.Net Project, and I have already been able to replicate the basic functionality of drawing sprites transparently, So I'm off to a pretty good start. I think that the XGSE guys just wanted to avoid dealing with VB.Net users during the beta since I can't find any problems using it with VB.Net yet.

I have run into another quesiton though. Using MDX 1.1 I was using the DrawUserPrimatives using a vertex buffer that contained a triangle list. That worked pretty good, and I had set up my code to minimize calls to SetTexture. This was because I was using Direct3D to simulate 2D graphics. This worked great since I coould specify a Z depth and the draw order was taken care of automatically by the Depth Stencil.

Now all the samples I've seen so far use the SpriteBatch class, which works, but I am curious how it handles things behind the scenes. It looks like I can do things in a fairly similar manner with the spriteBatch since one of its draw overloads takes the texture, source and destination rectangles as well as a layerdepth. which are the only parts crucial to me.

I suppose what I am wondering is the spriteBatch class going to be fast enough for me to call it a few hundred times with various textures and still expect a decent framerate?

Just to find out I did a simple test.

Scenario A - Texture A drawn 10000 times. This is a simple base line to compare against.
Scenario B - Texture A and B drawn Alternating 5000 times. This is a more difficult task based on the assumption it will cause more texture switching inside the device.
Scenario C - Texture A Drawn 5000 times, then Texture B drawn 5000 times. This task is designed to minimize texture switching.

Results (in Milliseconds)

A       B       C812.500 859.375 796.875812.500 828.125 781.250796.875 859.375 781.250828.125 828.125 781.250Averages812.5   843.75  785.15625

So it seems that speed difference is negligible between these three scenarios. Scenario A and C should be close as they are nearly the same with at best one texture switch. B should be the longest (and it was but only by a few ms) because at worst its lots of texture switches and at best lots of sorting.

Without knowing how the SpriteBatch class works, I would interpret this as meaning that there is no significant difference in the scenarios, but that the result could change if the vector and depth layer varied for each call.