Slick New Feature in SlimDX
The idea for this came up last night during a conversation with CodeImp. It's not implemented yet, but it should be fairly simple to write, and quite useful. I'll have to see exactly when it goes in; hopefully I can add it into the SVN this weekend.
So the basic problem is to handle a missing DX runtime. When .NET apps can't find a DLL that they want, they generate a FileNotFoundException. That kind of makes sense. The problem is that the error doesn't have any useful information, and to the user it just looks like the developer screwed up the packaging. And since DLLs are delay loaded, this exception can come up at a rather akward point, especially in the case of tools and other non-games who don't immediately start rendering things. Normally this shouldn't happen because your installer should have set up the runtimes correctly, but in the case of a damaged install or just an app that doesn't have an installer, it can be nice to do a check in the application.
SlimDX is adding functionality to do an explicit check for DX. I haven't nailed down the function names for this yet, but there will probably be one for each major component of DX. Essentially what these functions will do is to probe the relevant component of DX, forcing the DLL to load when called. This is done for each specific DLL and the exception is caught separately, and then wrapped as an InnerException of a subclass of DirectXException that gives some more detail about the problem. So for example, a call to CheckDirect3D could raise D3DNotFoundException in case DX9 is missing, or D3DXNotFoundException in case the specific version of D3DX is missing. You can catch those exceptions and give your user a meaningful description of the problem and solution. You can also define a precise failure point for your app in the event that something with the machine's setup is broken, rather than failing at some arbitrary point in the future when the runtime goes looking for a missing DLL.
It's this sort of thing that really makes me feel good about the SlimDX project. First of all, these new features serve as a useful differentiating and advertising point. I can point to it when someone asks what makes SlimDX different from MDX and it doesn't require long winded explanation. More importantly, though, it reflects a strong desire to adapt to developers' needs. That's inherent in everything from the design changes we've mdae to the license of the code itself. Hopefully, as the library matures a bit further, that will pay off for us and everyone else who's interested in the project.
