I've been working on way to many serious side-projects so I decided to play around with some WPF. I have always been curious at its potential for games. Of course it's not going to compete with high end engines and such but I think the capabilities it gives right off the start provides for some useful API's. Not to mention WPF has a nice animation engine built in, and tools such as Blend.

With the release this week of .NET 3.5 SP1 WPF comes with many amazing enhancements like BitmapEffects such as Blur, DropShadow, OuterGlow are now GPU rendered shader effects. This is made possible by WPF now supporting GPU shaders and you can even write your own! This opens the door for some very cool effects.

I'm not a gaming developer by any means but I do find it a bit fun to learn so I decided to tackle dynamic lighting in WPF. As far as I know I haven't seen many 2D graphical games that contain dynamic lighting. Usually the lighting is drawn right into the graphics I believe. I may be wrong.

I thought it would be cool if we could have a light in the scene, and the objects as they animate adjust their lighting according to their angle between the light. With the help from my friend Haro on IRC who helped me with the math for the angle calculation I was able to do the following:

Screenshot

Video

I really enjoy finding things that make me more productive as a programmer. I think LINQ is one of those advancements that when you learn it you could write some really efficient code.

Whenever I get a chance to throw some LINQ learning into a task I like to so that I can learn a little bit more. I am new at LINQ but enjoying every minute of it! Definitely is a different way of thinking about how you query and deal with any type of data.

This evening I have been learning the System.ServiceModel.Syndication namespace which allows you to publish/consume various types of syndication feeds like RSS and Atom.

In this particular case I needed to restructure an Atom feed slightly. SyndicationFeed.SaveAsAtom10() structures the XML like so:

   1: <feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom">

   2:   <title type="text">Digg </title>

   3:   <subtitle type="text">Digg </subtitle>

   4:   <id>uuid:9851e7e7-4574-4f7f-b44f-9c425d02d2d0;id=1</id>

   5:   <updated>2008-05-22T23:02:35Z</updated>

   6:   <link rel="alternate" href="http://digg.com/" />

   7:   <entry>

   8:     <id>...SomeID...</id>    

   9:   </entry>

  10: </feed>

However I needed the following (Don't ask, yes I know ID is redundant data lol):

   1: <feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom">

   2:   <title type="text">Digg </title>

   3:   <subtitle type="text">Digg </subtitle>

   4:   <id>uuid:9851e7e7-4574-4f7f-b44f-9c425d02d2d0;id=1</id>

   5:   <updated>2008-05-22T23:02:35Z</updated>

   6:   <link rel="alternate" href="http://digg.com/" />

   7:   <entry id="...SomeID...">

   8:     <id>...SomeID...</id>    

   9:   </entry>

  10: </feed>

In the API this is accessed via SyndicationItem.AttributeExtensions[] so we can do something like SyndicationItem.AttributeExtensions.Add(......)

We also need to access the id child element because we need its value. That can be accessed via SyndicationItem.Id property.

I need every entry element to contain an id attribute. I thought to myself, hey, wouldn't it be cool if I could use LINQ to do all this in 1 line? Hell yeah!

   1: feed.Items.ToList().ForEach(item => item.AttributeExtensions.Add(new XmlQualifiedName("id"), item.Id));

The feed object is of type SyndicationFeed.

How cool is that? I know, I know, I'm easily impressed sometimes :)

• Windows Mobile 6.1 Professional
• 528 MHz Qualcomm processor
• 192 MB SDRAM, 256 MB ROM, 4 GB internal storage
• 2.8-inch touchscreen with VGA resolution
• GPS and A-GPS ready
• Tri-band GSM/GPRS/EDGE (900/1800/1900 MHz)  HSDPA (900/2100 MHz)
• Wi-Fi (IEEE 802.11 b/g), Bluetooth 2.0 with EDR
• 3.2 megapixel camera with auto focus, VGA videoconferencing camera
• FM radio
• 3.9 inches by 2.0 inches by 0.42 inches (99mm x 51mm × 10.7mm)
• 900 mAh Battery

This device looks to be a real solid device. Specs are great, form factor and size, looks are great. One major downfall for me though is the lack of QWERTY keyboard. Almost 90% of what I do on my mobile device requires a keyboard so this is a huge missing piece.

The TouchFlo & included software though looks amazing. HTC is really taking the ball and running with it instead of sitting & waiting for Windows Mobile 7 to include better mobile/finger touch UI's. Their taking it into their own hands and its looking really good.

Example of the UI & device can be found here:
http://www.theunwired.net/?item=videoview-htc-touchflo-3d-user-interface-for-windows-mobile-professional

Let's hope there is a QWERTY slide-out style device with this same hardware/software package!

In part 1 I described the situation of transporting your data to the client end which in the past usually meant writing a business object layer to contain your data. You may be pulling it from an SQL database and placing them in objects, so that you can pass them along your servers & clients.

As mentioned in part 1 I call this the "plumbing". With LINQ to SQL along side with WCF and Silverlight, we can transport our data objects very easily and seamlessly all through the chain beginning with the database server, through the WCF service and finally to the Silverlight client like so:

I will show you how to achieve this, and properly set the environment so that all of the "plumbing" is automatically generated & handled by LINQ to SQL & WCF.

Get Started

I first started off by creating a regular Silverlight 2 application in Visual Studio 2008 with a web application. I named the project CarListing.

So here we have the Silverlight project at the top and the web application which hosts the Silverlight project below it.

Now let's add a Database to the CarListing_Web project.

Open the database in Server Explorer and Add New Diagram

We are going to use the diagram view because I find it a bit quicker to model a database than the table views.

Create your tables, setup proper Primary Keys & relationships
LINQ to SQL uses your database relations and setup to use in its object generation so it is key to have this setup properly for your objects to retain the proper structure.

Enter some test data

So now that we have some useful data we can use LINQ to SQL to generate our object model off of our database schema.

Add LINQ to SQL Classes to the CarListing_Web project

In the DataClasses Object Relational Designer drag all your tables into the design surface
You will see that it picks up on our One to Many relationship we created in our schema.

*** UPDATED ***
Firstly we need to enable serialization on our object model. This will allow WCF to serialize our objects.

Select anywhere in the design surface and open the Property Grid and set the following highlighted:

In part 1 I mentioned it would create an object relation such as User.Cars[] represented as a collection. However it will also create the link back the other way such as Car.User. This is problematic because we want to transport these objects over our WCF Web Service. Transporting objects over a web service means that the objects need to be serialized to XML. However the serialization will throw a circular reference exception because the objects refer to each other in a circular chain and it cannot serialize this. The serializer does not know when to stop.

Consider with this relation it would be possible to do the following: User.Cars[0].User.Cars[0].User.Cars[0] etc...
This means that we must break the circular reference to allow WCF to successfully serialize our data.

*** UPDATED ***
There are two ways to approach this. Unfortunately this is a bit of a pick your poison type decision we have to make. We need to disable the circular reference so that the serializer doesn't go in circles trying to transform our data for transportation over WCF. However doing this means that our client side (Silverlight) won't have access to both properties.

The relationship we have created here the User class is the parent, the Cars class is the child. Let's look at the Property Grid when selecting the link between the 2 tables in the designer:

So in the Property Grid we can see that we have options for both the Child Property and the Parent Property.

The Child Property would be User.Cars[] and the Parent Property would be Car.User

Since we must break the circular reference somehow we have 2 options:

1. 1. Disable Child Property.
   This means that User.Cars[] is disabled entirely meaning that both the server side (WCF) and client side (Silverlight) would be disabled. We would have to do extra querying to retrieve the Cars a User may be associated with.

2. Set the Access to Internal on either the Child or Parent property.
If one of the properties are not Public then it will not be serialized. The benefit of this option means that if our WCF Web Service required the relationship to be both ways then this would allow the service to access it unrestricted. Once you returned the object over WCF though since the property is Internal then you would lose that property on the client side.

I think #2 is the best option but which one do you mark Internal? I guess that decision should be dependant on which cases you think you require the most.

It's unfortunate I haven't been able to find a way to serialize both sides but somehow mark the property somehow so the serializer knows if it hits the same property twice not to keep serializing. If anyone knows how to get both sides of the relationship to serialize feel free to comment and I'll update my blog!

For the purpose of this example let's set the Parent Property to Internal so that we can have the User.Cars[] relationship serializable over WCF to the client end.

This step is a big key to your data seamlessly serializing over the wire and drastically simplifying our lives in the end.

It is past 1am now so I must hit the hay!

In Part 3 we will create the WCF Web Service along with a simple method to get a listing of cars. We will setup the Silverlight application to call the service to request the listing of cars and display the data. We will also get a peek at how the generated object relation of our database looks via code to create this method. You will find it exactly like targeting regular classes & collections. This means all the common API's we are accustom to are at our finger tips but instead leveraging a database.

See you tomorrow!