One of the things we’ve always been very careful to do with XPF is to make sure that it doesn’t really know anything about XNA. Everything is interface driven and the link to XNA is only made at the “last minute” in the implementation of those interfaces.
This gives us the advantage of easing our BDD specs (everything can be mocked) but it also opens up another intriguing possibility - XPF doesn’t necessarily have to be used for XNA.
To reinforce this separation we’ve introduced the concept of adapters. Those currently using XPF will know that we already have adapters, in the pattern sense of the word, for SpriteBatch, SpriteFont and Texture2D – but we’re extending the adapter concept to encompass everything required to use XPF on a platform, such as XNA.
There isn’t actually much new in the codebase as a result but we have moved some code about and created a new assembly. Alongside RedBadger.Xpf.dll you’ll now find RedBadger.Xpf.Adapters.Xna.dll. RedBadger.Xpf no longer references any XNA assemblies, but obviously the adapter dll does. (This structure is mirrored in the WP7 assemblies).
As it stands there is only one XPF adapter – XNA, but in time there maybe more whether they’re written by us or by you! We'll be publishing the source code for the XNA adapter in the near future and giving you a few more details on how you go about writing your own adapters, but in the mean time you’ll probably want to get the latest build, add a reference to the XNA adapter and fix up your code (should be fairly straight forward).
Other Changes (including Clipping)
Build 24 also brings with it clipping, which has meant a few changes to the way in which the SpriteBatchAdapter works. We needed finer grain control over the SpriteBatch Begin and End calls (we use Scissor Testing to perform clipping which requires a change in RasterizerState) so you’re no longer responsible for calling SpriteBatch.Begin/End either-side of your call to RootElement.Draw. To enforce this SpriteBatchAdapter no longer adapts SpriteBatch to ISpriteBatch via inheritance, but rather containment – so you physically can’t call Begin/End yourself. This is consistent with the other adapters, so actually provides some nice usage symmetry too.
As a lot of the graphics related code has now been moved out of the main XPF assembly, we’ve re-organised our namespaces a bit. Everything that was under Presentation has now moved up into the main Xpf namespace (Presentation is no longer). We’ve also renamed XnaImage and ITexture2D to TextureImage and ITexture respectively.
As always, let us know how you’re getting on with XPF and thanks to all those who’ve provided feedback thus far, it’s been invaluable!