I'm very happy to say that I will be presenting at an upcoming Atlanta Silverlight Firestarter on August 22nd in Atlanta at Microsoft's office. The event is free to the public and will be an all day Saturday event for anyone interested in learning more about Silverlight. I'll be there with several great Silverlight developers in the area as well as a few guys I am currently working with at IQ.
In my last blog entry I talked about how the new Bitmap API in Silverlight 3 gives you the ability to render controls to a WriteableBitmap, I also mentioned how it gives you direct access to editing pixels in a bitmap. I wanted to put together an example of what this ability can provide, and I wanted to show off how performant the get/put pixel abilities in Silverlight 3 actually are.
(click it!)
In the demo above you can see a fire algorithm (previously done in WPF and hacked up in Silverlight 2) as well as a text scroller - both of these are being rendered pixel by pixel. The bitmap the text scroller is manipulating was created by rendering a TextBlock with a drop shadow effect to a bitmap (read more on how to render text to an image here). By clicking on the demo you can see some simple elastic transitions being done on the rendered WriteableBitmaps - I was pretty impressed to see that even though tens of thousands of pixels are being manually rendered, the transitions performed very well (at least on my machine).
The ability to get/put pixels is exactly the sort of thing that will allow things like doom/quake/etc. to be ported to Silverlight - because you can bypass all XAML and just use a WriteableBitmap to manually render all of your UI at the pixel level.
One of the issues with getting and putting pixels with the Bitmap API in Silverlight 3 is that the direct pixel access is done by setting a pixel's color - which is an integer. Converting a Color to an Int when putting, or an Int to a Color when getting isn't exactly intuitive, so I wanted to post examples of both for others who might be giving this great new ability a whirl.
One of the new features in Silverlight 3 (released on Friday) is the Bitmap API which provides the ability to render UIElements to a bitmap and provides direct access to the pixel level information of bitmaps. This type of functionality is very useful in a handful of situations, but perhaps the most notable is the ability to cache out a rendering of a UserControl and make use of it in complex transitions to reduce overhead, or to facilitate editing images or processing images through filters, etc.
I did a few searches tonight to get started playing with the Bitmap API and found several examples, but unfortunately none of them had any source code attached, and were written against previous SL3 betas which had different method signatures relevant to the bitmap rendering, so I wanted to go ahead and post a simple example of rendering out a UIElement to a bitmap. This example shows the output of rendering a TextBlock at various font sizes and image sizes and setting the resultant bitmaps as the source for three equal sized Image UIElements.
(nothing exciting, at least for now)
In the attached code sample you'll see a method which creates a WriteableBitmap, and the resulting WriteableBitmap is set as the source for an Image UIElement. The code to render the bitmaps is very simple, the key (to not wasting your time) is to make sure that you always call Invalidate() on the WriteableBitmap before making use of it, otherwise you will never see anything in the created bitmaps. Here is the main rendering method:
I've been doing a bit of work at the new job on some custom panels relative to our project. In doing the work we have been talking a lot about the iPhone's main launcher panel and how the iPhone implements dragging and reordering of icons on the screen. I wanted to take what I have learned in working on those custom panels and apply it to actually recreating the iPhone's implementation - you can find what I came up with here:
For those that don't know, I have been a Winforms dev since about 2001. Before that time I was just as interested in graphics and usability as I was in coding itself. While in college I was pursuing a computer science degree in class, but my free time wasn't spent coding in Java or reading books on operating systems, it was spent in Photoshop and Flash 4. In fact, I was doing more advanced stuff in Flash Actionscript at the time than I was doing in my college CS courses. I had hoped that when it came time to graduate from college I would be able to get aboard the Flash bandwagon - creating super cool UI's for the web - unfortunately the dot com bubble burst, and my coding abilities were what kept me gainfully employed.
Up until creating an entry for the Server Quest Silverlight contest I had never touched Silverlight. I was definitely aware of it, but I was a Winforms guy, not a web guy - so I was elbows deep learning WPF and Prism and doing WPF LOB work for my current employer - I had no plans of touching Silverlight. Now that I've finished my first major Silverlight app, Matchingo, I find myself questioning which direction I want to go next - do I go back to WPF, or do I keep on trucking in Silverlight?
The initial code drop of Matchingo is now available on CodePlex at matchingo.codeplex.com. This release contains the same functionality set as is currently featured in the Server Quest Contest, but the code itself has undergone major refactoring since that initial release.
The Matchingo codebase makes use of various technologies including:
I am very pleased to announce the launch of Matchingo.com. Matchingo.com is the main hosting page for my new game Matchingo - a Silverlight implementation of a matching game.
Matchingo includes several features including the ability to replay every game you play, track all your high scores, choose from various card and background image sets, and more. Matchingo was developed using C#, Silverlight, and the Composite Guidance for WPF and Silverlight (aka Prism).
