At long last, I’ve finished the Bloom sample. You can get it here:
It is a near replica of the XNA Bloom sample written in C++ using DirectXTK and my Windows Store DirectX C++ Sample base. It’s large (almost 15 MB) due to the TGA texture files that the tank model uses. This release includes the version of DirectXTK released February 22, 2013. As always, any questions, comments, suggestions, and bug reports are welcome and appreciated. The sample makes use of some XAML UI, including both on canvas controls to let you mess around with various bloom parameters and a bottom AppBar that lets you switch between the presets that the XNA sample defined. With a touch screen you just swipe up from the bottom to make the app bar appear; with a mouse you right click to show it.
The code in this sample also shows how to load and render a model using DirectXTK. We use the same tank model from the XNA sample along with the same background image so that you can compare them side by side if you are coming from C# and XNA and learning C++ and DirectX.
All three C++ samples have an updated version of the Camera class, which now provides for both left-handed and right-handed matrices so that whether you are using .CMO files or .sdkmesh files, you can work in the correct coordinate system with the same instance of the Camera class. I have removed the old ambiguous GetProjectionMatrix and GetViewMatrix member functions and replaced them with Get*MatrixLH and Get*MatrixRH versions.
I’ve also added a frame rate display to the samples. It’s really only useful for detecting if you’ve dropped below 60 fps. You will find it in DirectXPage.xaml.cpp.
Starting with this sample, I added the concept of game components. I have gone back and added them to the sample base and the pixel perfect collision sample as well. You do not need to use them, but they can be helpful and I intend to use them more in future samples.
There are three interfaces: IGameResourcesComponent, IGameUpdateComponent, and IGameRenderComponent. Each is a pure abstract class and their use demonstrates what I consider to be one of the good uses of multiple inheritance in C++. The BloomComponent implements IGameResourcesComponent and IGameRenderComponent. It has no need of IGameUpdateComponent so it does not implement it. The current mechanics of adding and (especially) removing game components will be a bit difficult for anyone not very familiar with how std::vector works in C++. It is sort of like .NET’s List<T> class but some member function have different names than their .NET counterparts and some things work a bit differently than you might expect.
I’m strongly considering making the next sample a XAML UI-based take on the XNA Game State Management sample. If so, this will flex and stress the game component system I’ve introduced. This may mean the addition of some helper functions or perhaps even some large, breaking changes in the game component system. Starting with the next sample (whatever it is), I will be documenting any breaking changes that I make to other samples by adding a changelog file to each solution. I’ll still describe any changes in the blog posts, but this should help you with tracking what has changed and me with remembering what I have changed (without needing to dig through my source control commit messages and file diffs). Hopefully breaking changes will begin slowing down.
The only things I’m anticipating presently are some modifications to the game component system (definitely some additive changes and perhaps some breaking ones) and (at some point in the indefinite future) adding an XAudio2-based music engine to complement the existing Media Foundation based music engine. XAudio2 provides lower latency and more control but support for using it to play WMAs and MP3s via Windows Phone 8 isn’t there currently and my goal initially with the AudioEngine class was to have it be usable both for Windows Store and Windows Phone 8 apps and games (which it did when I last tested it, though I never did test the final version in a WP8 project so it’s possible that it might need tweaking to work there).
Fairly soon the base sample should crystalize into a final form that will need few, if any, changes other than maintenance releases to update to newer versions of DirectXTK. That’s my hope anyway; we’ll see!