SilverTile: Old-school gaming on a modern platform - progress report

8. desember 2009

It's time for a progress report.

The last week I have been adding basic features to SilverTile. The first feature was to add basic rendering support. My first attempt used Array-copy functions to copy pixel data from the sprite to the viewport. This worked well, but it did not support alpha blending (transparency) of pixel data. To improve this I added some code from the Silverlight Games 101 blog that allowed rendering of bitmap data from one WriteableBitmap to another. I modified the code somewhat to support rendering of data from any IRenderable and then I had the rendering support I needed.

The intial architecture of SilverTile defined each sprite object as having its own pixel data. This is fine as long as you have only a few sprites or if each sprite have an unique appearance, but in most cases you will have many sprites using the same image. One example is the walls of a game area. I model each wall segment as an unique sprite, but each is built up of the same image. So instead of having each sprite have its own pixel data I refactored out the pixel data into a Frame object that could be reused between sprites. This also lay the ground for animation support later.

Zelda walking

Link walking!

To set up a game area I want to support two modes. One mode should be building game areas in code by using the AddBackgroundSprite() method of the Viewport class. This lets you add one sprite at a time at the desired location. While building the game area in code works well, I wanted to support using Xaml to describe the game area and the graphical resources used by a game. Since Silverlight only allows classes that inherit from UIElement to be named (given the x:Name and x:key attributes) in Xaml I had a choice of either letting the Sprite classes derive from UIElement or using a separate set of classes to describe the game area. I cholse the latter option and built a set of classes that can be instansiated in Xaml and that describes a game area, a game tile and a frame. I then added a SetGameArea helper method to the viewport that reads the GameArea data and performs the setup.

Finally I added support for animated sprites. An animation is a list of IFrame objects in combination with a frame rate. Each time the Update method of the animated sprite is called, we check if the elapsed time is greater than the time a frame should last and if it is we switch frames to the next frame. When we reach the last frame in the animation we go back to the first frame again. Although I will need for sprites to support multiple animations (like walk left and walk right), this is a good starting point.

On top of all this I have written tests for everything. This really helped me when refactoring the code to use IFrame and the bitmap blitting.

If you have the Silverlight 4 beta installed you can watch a live demo here: (Try clicking on the game area!) Or you can download the source code here:


kick it on

.NET, Silverlight , ,


08.12.2009 15:10:51 #
SilverTile progress report

You've been kicked (a good thing) - Trackback from
Ole Gunnar Borstad
Ole Gunnar Borstad
09.12.2009 09:05:56 #
Stilig! Hvis denne framgangen fortsetter håper jeg du får tid til en presentasjon på jobb utpå nyåret om SilverTile!

Har du brukt mye tid på å tenke ut hvordan animering fungerer? Krever vel en god del kunnskap om SL og grafikkteori?
10.12.2009 14:10:03 #
Animasjon er faktisk veldig lett! Vi har en "frame" som bare er et bilde, og en animasjon som er et sett med flere bilder. Animering skjer ved at vi bytter ut hvilket bilde som vises når det aktuelle bildet har blitt vist lenge nok. Hvor lenge bildet vises bestemmes ut fra frame raten til animasjonen.

Add comment

  Country flag

The number (5) not with letters. This is to stop spammers.

  • Comment
  • Preview