Silverlight Games 101

In a recent article in The Register http://www.theregister.co.uk/2009/11/20/silverlight_4_windows_bias/ they make the case that COM support in Silverlight 4 has “crossed a threshold” that will make Silverlight less appealing to developers that want to do cross platform development.

Yes it is true that now there is a feature in Silverlight that is Windows only, but it is still a Beta and not a released product so it is possible that some Mac native integration will come as well. Clearly it would have to be different since Mac doesn’t support COM, but hopefully if added it would be done in such a way that the interfaces on native APIs on both platforms from Silverlight would be similar.

Adobe AIR 2 is also adding native API support, and I don’t have the details on how it all works, but clearly once you start making native calls there are going to be differences in how they are called because no two platforms are identical. One of the top feature requests for AIR 1.0 was native API integration, so this is definitely something people want.

The key point in my opinion is whether COM support makes it harder for someone to develop a cross platform application in Silverlight. I feel the answer is clearly “no”, simply avoid the COM APIs if you want a cross platform application.

You’re not forced to use the COM APIs, but if you want to provide extra functionality on Windows the COM interfaces can come in very handy for things like integration to Microsoft Office, and I look forward to seeing what people come up with using this new feature. There was, by the way, a Windows 7 only feature in Silverlight 3, the ability to use multitouch. And similarly, if you wanted to write a cross platform Silverlight app you would just avoid the multitouch library.

One of the complaints I always has about Java’s “write once run anywhere” approach was that it never took advantage of the strengths of the platform, so it felt like a second class citizen everywhere. I’m pleased to see COM support in Silverlight 4 and hope to see some Mac integration as well. So is Silverlight moving away from cross platform? I don’t think so, and they would be crazy if they did. I’m sure there were a lot of internal discussions on whether to provide this feature and they came to the conclusion that the benefits outweighed any backlash they might get.

Full source code: http://www.bluerosegames.com/BlitWriteableBitmapSample.zip

This post is partially inspired by René Schulte’s series on extending WriteableBitmap. You can see his fantastic posts here:

http://kodierer.blogspot.com/2009/11/drawing-shapes-silverlight.html

The other inspiration for this comes from efforts that I have been making with SilverSprite, an open source library to compile and run 2D XNA games in Silverlight. When rendering a lot of bitmap sprites to the screen using traditional Silverlight techniques of adding Images to the visual tree works fine for tens or even a couple of hundred of sprites, but add more than this and have them all moving around and this technique starts falling short.

There are some other issues as well, such as drawing with a tint or drawing with anything other than alpha blending. For cases such as these, I wanted to be able to offer an alternative and settled upon rendering (“blitting”) images myself to a WriteableBitmap. This functionality will make it into SilverSprite soon, but in the meantime you can take advantage of it now.

Following in René’s footsteps, I have implemented these methods as extension methods on WriteableBitmap. There are some overloads to simplify the call a bit, but they all end up calling this method:

public static void Blit(this WriteableBitmap bmp, Rect destRect, WriteableBitmap source, Rect sourceRect, Color color, BlendMode blendMode) 

Most of these parameters should be clear as to what they do. The part of the source bitmap that is specified is copied to the destination rectangle of the target bitmap. The image is scaled to fill the destination rectangle if the source and destination rectangle differ in size. The two parameters that need a bit more explanation are the color and blend mode.

The color, if not Colors.White, will tint the source image. You can specify a partially transparent color to draw with and the image will be drawn partially transparent.

The blend mode can be AlphaBlend, Additive, Subtractive, or None. AlphaBlend is what you’re used to with Silverlight, but it can be too limiting in some cases. Additive blending can be very useful. Instead of alpha blending the colors, the source and destination red, green, and blue colors are added together to get the resulting color.  Let’s consider 3 fully opaque circles, one each of red, green, and blue. With alpha blending, we get something like this:

Whichever one is drawn last ends up on top. If the circles were partially transparent, the values would be alpha blended. For additive, we get something like this:

The center is white because the red, green, and blue components are added together to make white. for subtractive we can start with a white background and draw:

This is exactly what you would get if you inverted the colors in the additive example. This makes sense because we’re subtracting color values instead of adding them, so we’re doing an inverse operation.

Finally, with blend mode None, The source pixels are copied as is to the target, and so the transparent areas of the source image are drawn overwriting the values that were there:

One place where additive blending is useful is with particles effects. Particle effects look more natural and impressive when using additive blending. Here is an example of using additive blending with particles. The particle emitter follows the mouse. The source code for this sample is included at the top of this post.