After a week of tearing my hair out trying to get my game XNA game working in Silverlight (Microsoft’s answer to Flash), I finally have my Black Triangle:

For those who don’t know, Jay Barnson explains:

The black triangle was a pioneer. It demonstrated that the foundation was finally complete, and we were now ready to put it to work doing cool stuff.

Actually it’s a spinning cat-girl, which I think has a better ring to it than “black triangle”. (PS: Click her for rainbow mode!)

“What is so special about a spinning cat-girl in Silverlight?” you might ask. Well, the magic part is that the same code also works in XNA – you can download the XNA version here.

Originally I had intended to use SilverSprite to provide my compatibility layer between XNA and Silverlight. As it turns out, the way SilverSprite does graphics is a colossal hack (and very buggy to boot).

The problem is that XNA is based around issuing a sequence of draw commands like “draw a box, draw another box”, whereas in Silverlight you have an object tree (that, for example, describes those boxes) that you can manipulate and that Silverlight will draw for you.

SilverSprite attempts to be a drop-in replacement for XNA, so it must find some way to pair stand-alone draw calls with objects in Silverlight’s object tree. The only way it can do that is by effectively guessing which objects should be moved, removed and created on each frame. This is extremely slow and error prone (did I mention that SilverSprite is buggy?).

My approach is instead to replace the draw calls in my game with my own object tree. In the Silverlight version, that object tree maps onto Silverlight’s object tree. In the XNA version I can just go through the object tree rendering each node.

[UPDATE: For those of you researching ExEn, I should point out that this is no longer the case. Based on what I learned doing the scene-graph approach, I figured out a way to do fast, reliable, immediate-style drawing in Silverlight 3. ExEn implements the full SpriteBatch class from XNA. It’s actually pretty clever, if I do say so myself. ExEn doesn’t use any of the rendering code from SilverSprite.]

The upshot of this is that I now have an excellent pathway for porting Captain Stretchy-Arms (and future games) between XNA and Silverlight. Stay tuned!

(PS: I was going to rant more about how obtuse Silverlight’s API is, and how poorly suited it is to doing high-performance and accurate graphics like those needed for games. But now that I have this working, I’m not really feeling that cross with it any more.)