SlimDX Sample Framework - Overview
So we've been looking to make SlimDX more user friendly lately. The SlimDX core is great, but it was missing some crucial elements that would make it a complete and well rounded package. My esteemed colleagues Josh and Promit began work on the build system, docs, and installer, which were three of the important elements we needed. I myself started the SlimDX Sample Framework, our answer to the niceties provided by the XNA Framework.
The Sample Framework is designed to be a quick and robust base for just about all new projects using SlimDX. It handles window management and device management for both Direct3D9 and Direct3D10. Anyone who's written the code necessary to enumerate the available devices and select the best one based upon given needs knows just how hard and tedious this process can be. Unfortunately, the first version wasn't ready for the June release, which ended up shipping with a stripped down and less featured version of the framework. The first major version was just recently completed and lives in the samples directory of the SlimDX repository.
One of the first goals of the framework is to provide a stable platform for new projects. When designing the framework, I had two major sources of inspiration to draw from: DXUT, and the XNA framework itself. DXUT, while extremely good at dealing with window and device management, falls on its face when it comes to the base architecture. When I first started building the Game class, I didn't look at either design, seeing what I could come up with on my own. After taking a look at XNA's offering, I was startled to realize how close the two designs were. This is a testament to how natural and intuitive the design for the XNA framework is, which makes it a great platform for the SlimDX framework as well.
In the end, I ended up going with a design straight out of XNA's book: inherit from the Game class, override the LoadContent and UnloadContent methods to deal with your assets, and override the Update and Draw methods to update and draw your game. It's a simple design that works quite well. DXUT ends up mixing the game management with the device management, making it ugly to use and compartmentalize. My design places all device management in a separate GraphicsDeviceManager class and all window management in a custom GameWindow class, derived from the .NET Form.
The custom window class has a few extra tasks on top of the normal set handled by the .NET form. First, it keeps track of the current monitor owning the window, and invokes an event whenever it changes. This allows other components, such as the GraphicsDeviceManager, to hook in and act accordingly. Second, it provides access to Windows events not normally exposed by the form class. Events for SystemSuspend, SystemResume, ApplicationActivated, ApplicationDeactivated, and Screensaver all allow the application to have much finer grained control over the system, which is necessary for games and DirectX applications in particular. Finally, the window class hooks into the resizing and state changing process, providing control custom tailored for DirectX applications.
The window class is only one of the major components of the new framework, and most certainly not the most complex. I'll discuss more about the remaining components in another journal entry. Feel free to respond with questions, criticisms, and concerns! All feedback is appreciated. We intend on developing this library until it is rock solid, which can only happen with large amounts of feedback to help iron out all of the flaws.
