Yet Another Coding Blog : silverlight

MVVM – This might hurt a little…

Avi Pilosof — Fri, 13 Nov 2009 21:23:57 GMT

This is an attempt at a collaborative post; I’ll fill in more data if/when people make suggestions; please add comments on more problems and other/better solutions – I’ll add the links.

Overall, MVVM is very attractive – but all the screen casts I’ve seen avoid some confusing pitfalls that you’ll come up against in the real world. The landscape at the time of writing is a plethora of frameworks that attempt to solve similar problems; I expect the community will settle on a small number eventually, and certain patterns will emerge.

Until then, I hope this will help.

Overall

Some things that you take for granted will seem impossible to do in MVVM (without breaking the rules). Sometimes this is due to Silverlight missing WPF features, other times it has nothing to do with that. Most of these holes are pluggable in some sense, which is why…:

Using a Framework

I recommend you use a framework. You can write your own, but please consider that it needs to handle quite a few things in order to solve the various problems in this article.

I can’t recommend which framework to use because I have no experience with them, but I do recommend considering the problems below and finding out how each framework solves them. If the framework doesn’t have a “reference application”, stay away – you’re going to need one.

Here are a few that I know of:

PRISM2.0, which is from the MS Patters&Practices group.

SilverlightFX, by NikhilK. Does alot more than just MVVM; great samples/posts.

MVVM Light

Lots of others

Reacting to a click

Scenario: User clicks button; you want something to happen.

Problem: You’re “not allowed” to use the codebehind and an event-handler, so it needs to be done in the ViewModel. However, the ViewModel is ignorant of the view, so it doesn’t know about the button’s existence – it can’t hook into the click event.

Solution: You need support for “commanding”. Put very simply, this is usually a broadcast/listen mechanism where a “command” gets raised by someone, and someone else chooses to listen to it. In this case, the button would raise a command, and the ViewModel would be listening for it, and act.

WPF has it built-in, Silverlight does not – but the various frameworks have tacked it on, and it’s a basic pillar of MVVM.

Opening a dialog

Scenario: You have a listbox, the user double-clicks on an element, and you want an edit dialog to pop up with that element’s data to be edited.

Problem: You’re not allowed to have logic in your code-behind, so you can’t simply react to the event there. So you raise a command, and the ViewModel listens to it… But it’s not allowed to reference a UI component such as a dialog!

Solution: Much as above, you use the broadcast/listen pattern… However, instead of having the ViewModel listen, you have some central app “router” listening, and it knows how to open a dialog.

Passing a value to a dialog

Scenario: Same as above.

Problem: You’ve raised the command, and it knows to open a dialog – but how does it know to pass in the currently selected item from the listbox?

Solution 1: Perhaps your framework allows that item to be set as the command argument as part of the XAML. If so, perfect. If not (or if you need something more complex):

Solution 2: Raise the command, but have the ViewModel listen to it instead of a central “router”. The ViewModel figures out what needs to be passed in (for example, a “CurrentlySelected” bound property on itself), and raises an appropriate command.

Closing a dialog

Scenario: You opened the dialog, the user made their edits and clicked “Save”, then the dialog’s ViewModel called the web service to save the changes. Now the dialog should be closed.

Problem: The last bit of code that ran was on the dialog’s ViewModel; it can’t tell the dialog to close because it has no notion on the dialog’s existence…

Solution 1: Some frameworks have built-in support for dialogs and will handle this.

Solution 2: Cheat; if you’re not a purist, try this: The ViewModel raises an event (“TimeToClose”) with an argument of success/failure. The View’s codebehind subscribes, and closes the view itself.

Animations

Scenario: Your app shows a list of servers, and their status is all “good”. The ViewModel loads some new data, and one of the server’s changes to “bad”. The UI needs to react by playing an animation for that server.

Problem: Fundamentally, you don’t want your ViewModel to know anything about animations, storyboards, VisualStates, etc. It changed the data, but all we have on the view side of things is how to display the data; what we really want is the ability to trigger a storyboard, or to bind an element from the ViewModel to a VisualState on a framework element.

Solution 1: You can try to cheat here by using the codebehind, but depending on your exact scenario it might not help at all.

Solution 2: This article seems to do a good job of replicating DataTrigger for Silverlight (although I’ve yet to experiment with this):

http://blois.us/blog/2009/04/datatrigger-bindings-on-non.html

Avi

Real-time list filtering with Silverlight, MVVM, and PagedCollectionView

Avi Pilosof — Fri, 30 Oct 2009 03:51:00 GMT

The Model-View-ViewModel pattern is very good for forcing clean UI code. Ideally, you want to end up with zero code in your .xaml.cs file – everything should be data-bound.

As nice as this sounds, sometimes it can get so tempting to break this rule in order to do something that should be simple. Here’s one example:

You have a ListView and a TextBox in the view; they are bound to an ObservableCollection and a string in the ViewModel. You want them to behave such that entering text into that box causes the ListView to filter its items:

The initial train of thought is like this: In the event handler for the TextBox, address the ListView and hide all the items that don’t match the filter. At least one problem with this is that you’ve broken your promise to keep logic in the ViewModel.

The second train of thought is: Since the TextBox is bound to a property on the ViewModel, add code to the property setter to remove all the items from the ObservableCollection which don’t match the filter.

This will “work”, and suck. The problem is that you’ve actually removed data, not filtered it. When the user changes the filter text, your collection no longer has the items you’ve removed – you need to reload them.

This is where the PagedCollectionView comes in. It’s a wrapper around another collection which serves the following purposes:

You can bind UI elements to it, and it will work like any other collection.
When wrapping a collection that implements ICollectionChanged, it bubbles the notification changes.
It has properties for setting filters (as well as sorting, paging, grouping).

So what you do is insert this object between your UI and your ObservableCollection, and just modify the filters on it. The data remains untouched, but the UI reacts perfectly.

Before:

After:

Here’s a simple example of the steps to take:

1) Create both the ObservableCollection and the PagedCollectionView, but only expose the latter as a property:

// This is the actual container of items that we're storing
private ObservableCollection<string> _RandomItemsBase;

// And this is the wrapper around it which we bind to. The PagedCollectionView
// allows for easy filtering, sorting, grouping.
private PagedCollectionView _RandomItems;
public PagedCollectionView RandomItems
{
    get { return _RandomItems; }
    set
    {
        _RandomItems = value;
        RaisePropChange(() => this.RandomItems);
    }
}

2) In the constructor, wrap the real collection with the PagedCollectionView:

_RandomItemsBase = new ObservableCollection<string>();
RandomItems = new PagedCollectionView(_RandomItemsBase);

3) When the entered text changes, call a method to filter things:

public string EnteredText
{
    get { return _EnteredText; }
    set {
        _EnteredText = value;
        RaisePropChange(() => this.EnteredText);
        UpdateFilter(); // Real-time filter
    }
}

4) And here’s the code to actually apply the filter to the view:

private void UpdateFilter()
{
    if (string.IsNullOrEmpty(EnteredText))
        RandomItems.Filter = null;
    else
        RandomItems.Filter = (o) => o.ToString()
                  .Contains(EnteredText);

    // Make sure to force a refresh of the view
    RandomItems.Refresh();
}

There is one interesting thing about the above snippet. Notice the lambda expression used to filter takes one argument (“o”), and I just call ToString() on it. Since the PagedCollectionView isn’t templated, the filter delegate is called with an argument of type object. You can then cast that object to whatever type you know the underlying colleciton uses. In this case, I have an ObservableCollection<string>, so I just call the ToString() method.

That’s it. It gets even cooler when you start applying sorting, paging and grouping to this view, then bind to it with a DataGrid, or something similar.

Avi

Silverlight RPG: Steel Saga

Avi Pilosof — Tue, 24 Mar 2009 07:34:14 GMT

My friend Darren who wrote the hilarious Buddy Knavery game has released a preview of his new project called Steel Saga.

http://www.steelsaga.com

It’s an old-style RPG written in Silverlight, and seems quite deep. At the moment there are only two “zones” (one outdoor and one dungeon), but Darren hates having a life, and is going to spend the coming weeks writing plenty more content.

Check it out; I still can’t believe one guy is doing all this work (programming, art, music).

Avi

Live Mesh Applications – whoah.

Avi Pilosof — Tue, 17 Feb 2009 01:52:02 GMT

I’ve been playing with Live Mesh for a long time now, and have been loving it. During this time I’d been hearing about applications for Live Mesh, and while it sounded interesting in theory I didn’t really get what the point would be.

Then I watched this video:

http://briangorbett.com/mesh/mesh-video-player/

The video walks you through the development process of a Live Mesh app. The “whoah” moment is when I realized that the one codebase - without any special code - created an application that ran identically on the web and on the desktop. Money shot starts at about 25:30; but it helps to watch the whole vid.

This is fascinating; this is a “Web OS” (I hate that term).

Avi

Drawing Fractal Trees - Part 3

Avi Pilosof — Thu, 24 Jul 2008 03:02:12 GMT

The Application Itself

Firstly, here's what we're aiming towards:

Live demo: Click to view live.

Download the code:

Screenshot:

Writing The Application

Now, when I originally wrote the bones of the app it was very simple; everything fit in the single Page.xaml.cs file; there's actually very little to it. Since then I've expanded it to cater for all sorts of UI niceties and expansion opportunities, so it's a little bigger (and that's what's in the ZIP above). I'll concentrate on the basics for the purposes of the blog post; you can download the full source and inspect the complexities.

Step 1: Creating the Final Command Set

This step involves taking the Axiom and a set of rules, and using it to generate a final set of drawing commands/operations. The method below is in a class called LSystem, which is also where the axiom and rules are stored:

   1: public string FinalCommandSet(int depth)

   2: {

   3:     string res = Axiom;

   4:     for (int i = 1; i <= depth; i++)

   5:     {

   6:         foreach (LSystemRule rule in Rules)

   7:         {

   8:             res = res.Replace(rule.From, rule.To);

   9:         }

  10:     }

11:

  12:     return res;

  13: }

Given the "depth" of recursion, we just loop through the latest string we have and apply all the rules at each step, starting with the axiom.

Now that we have this string, we need to walk through it and draw the final result.

Step 2: The Recursive Drawing Algorithm

   1: int DrawSegment(Canvas uiRoot, string commandString, int stringPos,

   2:                 Point curPos, double curAngle, double curLength)

   3: {

   4:     Random rnd = new Random();

   5:     int i=stringPos;

   6:     while ( i < commandString.Length )

   7:     {

   8:         char c = commandString[i];

   9:         switch (c)

  10:         {

  11:             case '[':

  12:                 i = DrawSegment( uiRoot, commandString, i+1, curPos,

  13:                                 curAngle, curLength );

  14:                 break;

15:

  16:             case ']':

  17:                 return i;

18:

  19:             case 'F':

  20:                 Point newPos = FromAngleAndMagnitude(curPos, curAngle,

  21:                             curLength + rnd.Next(this.Randomness/3));

  22:                 DrawLine( uiRoot, curPos, newPos );

  23:                 curPos = newPos;

  24:                 break;

25:

  26:             case 'P':

  27:                 if ( this.DrawPetals && (rnd.Next(100) < 90) )

  28:                     DrawPetal(uiRoot, this.Petal, curPos, curAngle);

  29:                 break;

30:

  31:             case '-':

  32:                 curAngle -= this.Angle + rnd.Next(this.Randomness);

  33:                 break;

34:

  35:             case '+':

  36:                 curAngle += this.Angle + rnd.Next(this.Randomness);

  37:                 break;

  38:         }

  39:         i++;

  40:     }

41:

  42:     return i;

  43: }

First thing to note here is that the function is meant to be called recursively. The cases for '[' and ']' (lines 11 and 16) deal with that.

Next up, notice the overall loop; it's pretty much: "Step through each character of the string, act on that character, update our current pen settings (angle/position) as you go, and then move onto the next character."

Notice also that the function returns the final position in the string (i)that it ended up on; this is so that when you call it recursively, it reads as far as it can, then tells the caller where to continue from (see line 12).

At each call to the function, we pass in these args:

uiRoot	The canvas to which we'll be adding any drawn lines. This is the same through all recursive calls.
commandString	The original/total string of commands. Stays the same through all calls.
stringPos	The current position in the command string; this changes through each recursive call.
curPos	The current position of the "pen" on the canvas; starts at the tree's origin, and changes with invocation of 'F'.
curAngle	The current angle/heading of the "pen" on the canvas; starts at 90 degrees, and changes with invocations of '+'/'-'.
curLength	The current length of a line when drawing with 'F'. This usually remains constant, but I added it in to allow for some funkier fractals that shrink with each recursion.

Step 3: Drawing a Line

Finally, drawing a single line on the canvas is a matter of adding a Line shape to the canvas's Children member (slow, but simple). However, we only know the current location, the direction of the line, and the length. We need to convert this to a Start/End set of points.

A little trig:

   1: private Point FromAngleAndMagnitude(Point origin,

   2:                 double angle, double magnitude)

   3: {

   4:     double radians = DegreesToRadians(angle);

   5:     return new Point(

   6:         (int) (magnitude * Math.Cos(radians)) + origin.X,

   7:         (int) (magnitude * -Math.Sin(radians)) + origin.Y

   8:     );

   9: }

And that's pretty much it. Everything else is window dressing!

Further Reading

Here's what happens when you take this technique just a little further: http://www.speedtree.com/gallery/
Here's more info about the topic in general: http://vterrain.org/Plants/
Here's info about using fractals to generate whole scenes (not just plants): http://vterrain.org/

Avi

Turn down the ugly...

Avi Pilosof — Wed, 23 Jul 2008 05:42:28 GMT

I've always struggled with making my apps look decent. In my head I can picture how it should look, but when it comes down to it, I often end up with stuff that looks like a dog's breakfast.

Here's the cure:

http://blogs.msdn.com/corrinab/archive/2008/07/22/8764478.aspx

That post in particular helped me understand how to use Blend to turn down the ugly; but Corrina's blog in general is good for those of you who use Silverlight.

Lose the borders on your ListBox and your app will already look way better :)

Avi

Drawing Fractal Trees - Part 2

Avi Pilosof — Sat, 19 Jul 2008 06:06:55 GMT

L-Systems

We've established that drawing the tree will use the concept of self-similarity. To put this in action, we're going to use what's called an L-System. Here's a crash-course...

Firstly, we establish that we have a "pen" that at any given time has a current position and a current heading/angle. It's always touching the paper, so when it moves forward, you get a line drawn. If you ever learned LOGO in school, this will be familiar.

Let's define a very simple set of operations.

Operator	Meaning
F	Move forward by a fixed amount.
+	Turn a little to one side.
-	Turn a little to the other side.
[	Remember your current position and heading, and store in a stack for later retrieval.
]	Retrieve the previous position/heading from the stack.

So if we feed something like "F+F+F+F" to our pen, we'll get a square, provided the angle that "+" uses is 90 degrees.

Take something a little more complex, such as "F[-F][+F]". This will draw a Y shape; walk it through on paper and see. The key thing to connect at this point is that the "[" and "]" characters are perfectly represented by a recursive call to the same function that's doing the drawing. Save that for later.

So we have our set of operators, we need one more thing: A way to generate an interesting string of operations that will draw the tree. The way we do that is by defining two things:

A starting point; an "axiom".
A rule (or set of rules) that transform a given set of operations into a new set of operations.

We then keep applying these rules to the resultant set of operations (starting with the axiom) as many times as we want. For example:

Axiom: F
Rule: F => +FF (this reads as: "Every time you see an 'F', replace it with '+FF'")

Execution example:

Iteration #	Current Set of Operations
0	F
1	+FF
2	++FF+FF
3	+++FF+FF++FF+FF

Feed the final string above into our "pen", and it will draw stuff. Not a tree though; not with that rule. If you want a tree, go with a rule like this:

F => FF-[-F+F+F]+[+F-F-F]

Wait, what?! Doesn't look anything like a tree, does it? But it turns out that when you apply that rule a few times to the axiom "F", it generates a set of operations that draws something very similar to a tree (depending on what angle you rotate with each +/-).

Check it out:

There is no randomness in this image; it's a direct drawing of the above rule (with 3-4 iterations of the rule), using a fixed distance for F and a fixed angle for +/-. Altering the distance that the pen moves with each F will make a larger/smaller tree; altering the angle can make a profound difference to the shape.

There are different rules that will produce different looking plants. For more examples, see this page.

To me, this is mind-blowing. That such a simple system with such basic rules and operations can generate something that looks so eerily "natural" is a little spooky. And reminds me that I had the same effect with the physics tutorial: Simple rules can make complex behaviour. I think there's some deep philosophical insight buried there.

What's left to do now is take this knowledge and apply it to a Silverlight program that can allow the user to alter the parameters in real-time, introduce some randomness, and maybe a little more life to the image.

Stay tuned...

Avi

Drawing Fractal Trees - Part 1

Avi Pilosof — Sat, 19 Jul 2008 04:02:20 GMT

Table Of Contents

Part 1: Basic fractal theory (this page)
Part 2: L-Systems - drawing trees.
Part 3: Implementation in Silverlight, live demo, code download.

A Brief Explanation of Fractals

In plain English, a fractal is a shape whose constituent parts are really just copies (scaled down) of the whole. Here's a simple example, the Koch Curve:

Take a look at the first part made up of 4 line segments. Make a copy of that whole part in your head, shrink it down, and rotate it so that it fits on top of one of the line segments. Notice how that looks like the beginnings of the second part? Keep going (forever), and that's your fractal: Any little bit of it is just a scaled down copy of the rest of it. You can zoom in infinitely and keep seeing the same pattern.

It's a very powerful concept that can generate stunning images when taken further.

But what really strikes me about fractals is that they're real; they're everywhere in the physical world. From lightning to river networks to broccoli to the layout of African villages! And also, to trees, which is where we come in.

Fractals in Trees

If you look at the "Y" shape created by a stylised tree branch, it's identical in concept to the branch that it spawned off, which is identical to its parent branch, etc, etc, until you reach the trunk - which forms the "axiom" of this fractal.

This series of posts will describe a Silverlight program based on this observation that allows users to generate random fractal plants by defining an axiom, a rule to iterate over, and a set of preferences that they can tweak.

Avi

[The Global] War On Terrier

Avi Pilosof — Thu, 17 Jul 2008 04:46:09 GMT

I mentioned in the last series of posts that I'd written a small Silverlight game for an internal competition. Well, I'm finally able to put it online, here it is:

http://silverlight.net/samples/2b2/waronterrier/waronterriertestpage.html

It's very similar to the old Worms games (which I love!), but much simpler. The reason I used puppies? Because my colleague suggested "War On Terrier" as a name, and while "Wombat Combat" was better, it's really tough to draw a cute cartoon wombat.

I think that programmers in general find it difficult to share their code with others because they rarely feel it's good enough, and we're a judgmental lot. I am no exception :) But here's the code anyway:

Download the code

I know it's not great code, so here come the excuses: Zero up front planning went into it; it was written in 2-3 hour bursts over the course of a few weeks; it was my first Silverlight program.

Now that those are out of the way, let me point out what I found difficult in writing this game:

XAML! My god, the amount of time I spent trying to figure out why my polyline didn't fit in the grid and how to scale it to fit and scale many polylines together and why the boundaries of the canvas were so big and why the transform origin was wonky and why things move when they shouldn't and why this won't wrap, and, and... Suffice to say, my XAML-fu is very weak.
The game is turn based, but within a given turn it will also switch to being physics based and also Silverlight animation based. This forced me to write a big state machine for the game which complicated the code alot. Basically, I had to do things like this in many places: "If we're waiting for an animation to complete, then do nothing this frame."
Learning how to use Silverlight user controls as my game objects, and how to structure the project around that. Do I load the XAML at runtime from a resource? Do I create actual user controls for each "image" in the game?
XAML - did I mention that?

That having been said, it was alot of fun getting it to work. Here's what really needs to be added to the game:

Network play. This would be way more fun if playing against other humans.
Allowing the characters to be moved along the screen.
More crazy weapons, different types.
Bonuses, hazards, etc.
Music.
Different scenes.

I hope the code is useful to someone, and that it doesn't lead you too far astray. Feel free to do whatever you want with it; if you have any doubts or questions as to why I did something, post a comment. I'll likely answer: "Because I wasn't thinking straight at the time" :)

Avi

Trivial Physics Simulations (...in Silverlight) - Part 5

Avi Pilosof — Tue, 24 Jun 2008 02:09:00 GMT

The finished product:

I'm having trouble finding a way to embed the SL app inside this page, so let's see if this works (c'mon, skydrive!):

CLICK HERE TO SEE THE APP IN ACTION.

And download the solution from here:

Taking it Further

Particle systems are the basis for lots of very high tech graphics effects such as fire, smoke, water, and explosions. Perhaps that's no longer the state of the art - but it used to be :) Anyway, with extra work, you can simulate the above to some degree of realism.

Aside from that, the physics we've created here aren't just for particles - you can use them in games for any simple physics-based motion (space ships, cars, projectiles). I say "simple" because things start to change if you want realistic physics that take into account the shape of the object and how it reacts to its environment.

Here are some ideas:

Direction: Currently, our particles are drawn as simple circles. Let's say we wanted to upgrade them to space ships. In that case, we'd get a terrible effect where the spaceship changes direction without actually rotating - nowhere in our code do we rotate the visual based on the direction (which is a function of its velocity). This could be fixed by adding a RenderTransform at the FireworksRenderingHelper level.

If you do that, you'll be 80% of the way there, but you'll notice that as the direction of the ship changes, the rotation can "flip" suddenly, which is unnatural. The reason for this is because the code we've written simulates a body being acted upon by simple outside forces; but a spaceship actually introduces its own forces (thrust). See more below...

Forces: We haven't talked about the concept of "force", but it's at the heart of real physics. We've hard-coded the acceleration to simulate gravity; but in reality, gravity applies a force, which causes acceleration. If you wanted to simulate a spaceship, you'd be better off altering the acceleration based on the force created by its thrusters, rather than having a fixed acceleration.

Introducing forces to the animation can make the realism really jump to the next level, because you start "feeling" inertia. But keep in mind that there's no force without mass, so bust out this equation:

F = ma

Or for our purposes:

a = F/m

Where "a" is the acceleration, "F" is the force being applied, and "m" is the mass of the object being pushed. The heavier the object, the slower the acceleration.

Obviously, this would add to the inner loop for the particle - but the basics are the same: modify the acceleration based on the force, the velocity based on the acceleration, and the position based on the velocity.

Friction: The current simulation has no mention of friction. The most obvious one is air resistance, but depending on what you're simulating, there could be others. I won't go into detail here because friction can be complex depending on the scenario; but it's essentially another force acting on the object. It can be a matter of reducing the acceleration, it could be tied to velocity, it could be tied to mass, materials, etc.

Angular Momentum: Getting fancier, you might want to give particles an angular velocity (or acceleration) - rotation. Let's say you smack a cube on the corner; it's going to both move and rotate. If your particles are being rendered as anything but tiny dots, it makes sense to add a component for that. In 2D, it would probably be of type double, units "degrees per second", or something like that.

Visuals: This is where you can really go nuts. In my youth (on my beloved Amiga, RIP) I wrote a program which rendered animations of explosions, smoke and lightning. All used a particle system like this, but altered the way that individual particles were rendered. All used a particle whose transparency fell off near the edges - you can probably do this in SL with a RadialGradientBrush - and whose colour changed over age. For example, an explosion particle went from bright orange to gray (as it turned into smoke). It actually turned out very beautiful and quite realistic (well, the 2nd version, anyway).

As you can see, there's lots of room for improvement and creativity. If you want to get into a more detailed physics simulation, I recommend this book:

http://www.amazon.com/Physics-Game-Developers-David-Bourg/dp/0596000065

Once you get into collisions between oddly shaped bodies and working out how they come to rest; that's when things start getting really complex.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 4

Avi Pilosof — Tue, 24 Jun 2008 01:52:33 GMT

Tying it all together has zip to do with the physics simulation, but there are a couple of interesting bits which I'll paste into here. The rest you can grab from the solution that I'll post up; feel free to ask questions.

The Game Loop

The heart of the app is a method call which renders one frame only. The trick is calling that method for each frame, and having that method do a very simple fixed set of operations that updates the particles for that frame only.

For the "call-each-frame" part, I use a very nice method stolen from Bill Reiss:

http://silverlightrocks.com/community/blogs/silverlight_games_101/archive/2008/03/28/the-start-of-a-game-helper-class-library.aspx

Each frame, that loop calls my method:

   1: void _GameLoop_Update(TimeSpan elapsed)

   2: {

   3:     AddNewParticles();

   4:     UpdatePhysics(elapsed);

   5:     _Renderer.Render();

   6:     RemoveDeadParticles();

   7: }

This method does the following:

Checks to see if we've got as many particles as the user wants us to have, and if not, adds a few more. I only add a small [random] number each frame, to avoid creating large spurts.
Updates the physics for all particles by calling each particle's RunFrame method. Because this uses the elapsed time since the last frame, the particles maintain a correct speed on-screen, even if the frame rate drops/increases.
Renders the particles to the canvas. More on that soon.
Removes any particles that have died, to prevent the particle list from growing indefinitely.

Generating Particles

The AddNewParticles method is where you need some creativity, and is the method you would alter if you wanted to change the nature of the fireworks (say, to create an explosion effect instead of a fountain). This method relies on simple heuristics to generate initial velocities. Here's the relevant bit:

   1: // Generate some random starting conditions for this particle

   2: Vector2D vel = Vector2D.FromSpeedAndAngle(200 + this.MaxSpeed,

   3:     ((180 - this.SpreadAngle) / 2) + rnd.Next(this.SpreadAngle));

   4: double milliseconds = 200 + rnd.Next(3000);

   5: double radius = 2 + rnd.Next(10);

   6: Color color = FireworksColours[ rnd.Next(FireworksColours.Length) ];

It's really all in lines 2 & 3: The initial velocity of the particle. We use the user's UI selections as limiters to random values. The more randomness, the more "natural" things look.

Rendering Particles

In making some effort to separate the logic of the physics from the UI rendering part, I created a FireworksRenderingHelper class that is given a list of FireworksParticle and a Canvas, and knows how to render one to the other.

Pre-Silverlight, I'd reset each frame, clear the background, render all particles, and show the frame. But with Silverlight, it already has internal methods for drawing objects to the screen, buffering, etc. So what I do is add my shapes as the Canvas's children and let it draw.

The catch is that I don't want to remove/add all the children each frame - it seems wasteful. This is why I added the Custom field within FireworksParticle - I use it to track a reference to the child of the canvas. At render time, if the field is null, I create a new Ellipse as a child and add it to the canvas. If it's not null, then I retrieve it and modify its position. Here are the loop internals ("p" is the current particle):

   1: UIElement canvasChild;

   2: if (p.Custom != null)

   3: {

   4:     canvasChild = (UIElement)p.Custom;

   5: }

   6: else

   7: {

   8:     canvasChild = new Ellipse()

   9:     {

  10:         Width = p.Radius,

  11:         Height = p.Radius,

  12:         Fill = new SolidColorBrush(p.GlowColor)

  13:     };

  14:     p.Custom = canvasChild;

  15:     _Canvas.Children.Add(canvasChild);

  16: }

17:

  18: canvasChild.Opacity = 1-p.Opacity;

  19: canvasChild.SetValue(Canvas.LeftProperty, p.Position.X);

  20: canvasChild.SetValue(Canvas.TopProperty, p.Position.Y);

Removing Dead Particles

The one non-trivial thing about this is that you can't use a simple foreach loop and remove any particles where Alive==false. Doing so would be modifying the collection while enumerating it, and you'd get slapped by the runtime. Normally, you'd get around this by separating things into two steps (get the list of dead particles, then remove them individually).

It seems that LINQ allows you to do this in one line, and I think it's due to the ToList() in there:

   1: private void RemoveDeadParticles()

   2: {

   3:     _Particles.Where(p => !p.Alive).ToList().ForEach(p => _Particles.Remove(p));

   4: }

In the final installment, I'll post the zipped up solution (and if I can work out how, the actual Silverlight app), and I'll explain how you can take this further.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 3

Avi Pilosof — Mon, 23 Jun 2008 23:55:38 GMT

So now that we have vectors, we need to do something with them. We're going to use the concept of a Particle. This is supposed to represent a tiny object in our world that is affected by physics. For this reason, it has a position, velocity, acceleration, etc.

For starters, let's define the basic particle:

   1: public abstract class Particle

   2: {

   3:     protected TimeSpan _Age;  // How old is the particle right now?

4:

   5:     public Vector2D Position { get; set; }

   6:     public Vector2D Velocity { get; set; }

   7:     public Vector2D Acceleration { get; set; }

   8:     public TimeSpan MaxAge { get; set; }

   9:     public bool Alive { get { return (_Age < MaxAge); } }

  10:     public double Radius { get; set; }

11:

  12:     public Particle(Vector2D pos, Vector2D vel, Vector2D acc, TimeSpan maxage, double radius)

  13:     {

  14:         Position = pos;

  15:         Velocity = vel;

  16:         Acceleration = acc;

  17:         MaxAge = maxage;

  18:         Radius = radius;

  19:         _Age = TimeSpan.FromMilliseconds(0);

  20:     }

21:

  22:     /// <summary>

  23:     /// Iterate one frame of animation for this particle.

  24:     /// </summary>

  25:     /// <param name="timeSinceLastFrame">How much time has passed since the last frame?</param>

  26:     public void RunFrame( TimeSpan timeSinceLastFrame )

  27:     {

  28:         double secondsPassed = (timeSinceLastFrame.TotalMilliseconds / 1000.0);

  29:         Velocity += Acceleration * secondsPassed;

  30:         Position += Velocity * secondsPassed;

  31:         _Age += timeSinceLastFrame;

  32:     }

  33: }

A few things to note:

It's an abstract class. Depending on your use of it, it doesn't have to be. This is actually a ready-to-go particle; it just doesn't have anything in terms of visuals attached to it.
Note the concept of "Age" in there (lines 3, 8 and 9). A particle lives for a while, then dies. It doesn't have to - but for most particle based simulations, you do want that.
The "Radius" property is supposed to indicate the size of the particle. It could be argued that this belongs in a subclass.

The only real point of interest is the RunFrame method on line 26. This is the key to the whole physics simulation. Remember I said that it's down to two lines of code? Those are 29 & 30 - the rest is fluff. We call this method every frame, telling it how long since the last call, and it will move the given particle in the right direction by the right amount.

So now that we have this abstract particle, let's use it to make something a little more specific to our fireworks demo:

   1: public class FireworksParticle : Particle

   2: {

   3:     public object Custom { get; set; }

   4:     public Color GlowColor { get; set; }

5:

   6:     public FireworksParticle(Vector2D pos, Vector2D vel, Vector2D acc, TimeSpan maxage, double radius, Color color)

   7:         : base(pos, vel, acc, maxage, radius)

   8:     {

   9:         GlowColor = color;

  10:     }

11:

  12:     /// <summary>

  13:     /// Fade the opacity of a particle as it gets older

  14:     /// </summary>

  15:     public double Opacity

  16:     {

  17:         get

  18:         {

  19:             double pctOfLifetime = ((double)_Age.TotalMilliseconds) / ((double)MaxAge.TotalMilliseconds);

20:

  21:             if (pctOfLifetime > 1)  pctOfLifetime = 1;

  22:             if (pctOfLifetime < 0)  pctOfLifetime = 0;

23:

  24:             return pctOfLifetime;

  25:         }

  26:     }

  27: }

You'll see we're only adding two things, both tangential to the core of this topic, but we need a little bling: The particle's color and opacity - the latter being a function of its age; it dims as it grows older.

Oh, and the Custom property. I'll get to that later; it's totally an implementation detail and not necessarily a pretty one.

So, what are we missing at this point?

We need a page to put all this on, with some UI controls for playing with variables.
We need some way of rendering the particles to the page (there's no drawing code above - I prefer not to put it in these classes).
We need to actually create particles with positions and velocities that will suggest some kind of fireworks.
We need code to tie it all together; the rendering, the UI, the particle generation.

Here's a screenshot of what the end result will look like:

(Yeah, no beauty contest winner - but it's effective :))

Next up: Putting it all together.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 2

Avi Pilosof — Mon, 23 Jun 2008 04:26:20 GMT

If you know how vectors work, this isn't going to be interesting. If you've never seen one before, I'll try to keep it simple. Keep in mind that throughout this post I'm talking in 2 dimensions. The same stuff applies for 3D work; you'd just add another variable (the Z component) to the vectors.

A 2D vector stores two numbers which can be used to describe the position of an object (X, Y), or the velocity (X = the speed along the X axis, Y = the speed along the Y axis).

So take for example an object that's traveling at a speed of 10 pixels per second directly northeast:

The red line (marked "v") is the actual velocity (10 pixels per second), while the dotted blue lines indicate the speed along the x-axis (vx) and the y-axis (vy). Essentially, we've "decomposed" the one diagonal line into one horizontal and one vertical. For now, we're going to leave the details at that.

At the very least, here's what a Vector2D needs to know how to do:

Store the X/Y components
Add two Vectors to each other (eg; add acceleration to velocity)

So here's the code:

   1: public class Vector2D

   2: {

   3:     public double X { get; set; }

   4:     public double Y { get; set; }

5:

   6:     public Vector2D(double x, double y)

   7:     {

   8:         X = x;

   9:         Y = y;

  10:     }

11:

  12:     /// <summary>

  13:     /// Add two vectors and return the resultant vector

  14:     /// </summary>

  15:     public static Vector2D operator +(Vector2D v1, Vector2D v2)

  16:     {

  17:         return new Vector2D(v1.X + v2.X, v1.Y + v2.Y);

  18:     }

19:

  20: }

At this point, we can do stuff like this:

   1: Vector2D acceleration = new Vector2D(0, 10);

   2: Vector2D velocity = new Vector2D(50, -50);

   3: velocity += acceleration;

That's probably sufficient to write the engine, but there are a few other features we'll want which will make the eventual code cleaner. Specifically:

Scale the vector by a fixed amount.
Generate a vector given an angle and a speed.

Why do we want that second one? Well, let's say you want to write code to generate the vector in the hand-drawn scribble above. What values do you give for vx and vy in order to generate the speed of 10 pixels per second in the northeast direction? You'd actually need to calculate them using some trigonometry, and that's some ugly code to have to read at a high level; so we bury it in the Vector class.

Eventually, we want to be able to do this:

   1: // Init from a speed (10 pixels per second) and an angle (45 degrees)

   2: Vector2D velocity = Vector2D.FromSpeedAndAngle( 10, 45 );

And here are the methods we want to add to the above class:

   1: /// <summary>

   2: /// Scale the vector by the given amount (ie; multiply by a scalar)

   3: /// </summary>

   4: public static Vector2D operator *(Vector2D v1, double scale)

   5: {

   6:     return new Vector2D(v1.X * scale, v1.Y * scale);

   7: }

8:

   9: /// <summary>

  10: /// Convert the given angle (in degrees) to a vector with origin

  11: /// (0,0) and length == speed, breaking down into the X/Y components.

  12: /// </summary>

  13: public static Vector2D FromSpeedAndAngle(double speed, double degrees)

  14: {

  15:     double radians = Vector2D.DegreesToRadians(degrees);

  16:     return new Vector2D(Math.Cos(radians), -Math.Sin(radians)) * speed;

  17: }

18:

  19: protected static double DegreesToRadians(double angle)

  20: {

  21:     return angle * (Math.PI / 180);

  22: }

For now, we're done with the Vector2D class. As I promised, it's quite trivial. We might add a couple of helpers here and there if we need them, but they will be obvious.

The key thing to remember about Vector2D is that it inherently stores both the magnitude and direction of the motion. So not only will it tell us the direction something is going in, but how fast it's doing it. This allows us to use it interchangeably for velocity/acceleration/position, and have everything "Just Work".

Next up: The Particle class.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 1

Avi Pilosof — Mon, 23 Jun 2008 03:34:39 GMT

Table of Contents:

Introduction

I recently wrote a small Silverlight game for an internal competition and a friend asked me how I did the projectile trajectories. Turns out that something which looks cool in practice is one of the simplest algorithms of all time (two lines of code!), and which I guarantee you learned in highschool science class; although they didn't call it an "algorithm", they called it a "formula". The cool thing is that it can be used to generate fairly complex visuals, by adding just a little extra spice.

I'm going to write up a short series demonstrating how to simulate fireworks in Silverlight using a very basic physics engine. At the end, we should have a nice interactive simulation to play with.

To start off, let me get back to the basic physics equation which underlies this whole thing:

v = u + at

To paraphrase this: "The velocity (v) a after some time (t) will equal the initial velocity (u), plus the acceleration (a) multiplied by the time (t)." Alternatively, to really get to the heart of the matter:

"Acceleration makes things go faster [or slower!] over time."

Now let's look at the units of measurement:

Time: seconds
Acceleration: pixels per second per second
Velocity: pixels per second
Distance: pixels

I think Newton may have been using the outmoded "meters" rather than pixels when he came up with this stuff; but it won't matter as long as the unit is consistent throughout.

Now, when you think about those units of measurement above, you notice that acceleration is just a measure of how velocity changes, and velocity is just a measure of how distance changes. So the whole physics simulation, at its core, is this set of two lines:

   1: while ( true )

   2: {

   3:     position += velocity;

   4:     velocity += acceleration;

   5: }

In other words:

"Every frame, the position of the object changes based on its velocity, and the velocity changes based on the acceleration."

Run the contents of that loop for each frame, and you have yourself a simple physics simulation.

One big thing that seems to be missing above is the direction of motion. It actually isn't missing - It's hidden in the type of those variables:

   1: Vector2D acceleration = new Vector2D( 0, 10 );

   2: Vector2D velocity = new Vector2D( 50, -50 );

   3: Vector2D position = new Vector2D( 0, 0 );

What's a Vector2D? It's a custom class that stores both a X component [of motion] and a Y component, and knows how to add/subtract them. Turns out that the WPF Vector class was taken out of Silverlight, so we need to write our own. Also turns out that this is trivial.

With this simple algorithm, by merely changing the initial velocity, you can simulate lots of simple phenomena:

A ballistic trajectory, by giving a high initial velocity in the direction the gun is pointed.
An explosion, by creating lots of fragments that have large initial velocities radiating in a rough circle from an origin.
A fountain, by continuously creating particles that radiate roughly upwards from a single point.

Stay tuned... Next up; the Vector2D class.

Avi

Buddy Knavery - The Killer Riffs

Avi Pilosof — Fri, 13 Jun 2008 00:21:03 GMT

Some Silverlight goodness. My friend Darren wrote this amazing game that has strong ties to those 90's adventure games that I miss; Kings|Space|Police Quest, Leisure Suit Larry, etc. Writing a game engine is one thing, but doing all the artwork & scripting while holding down a full time job (at MS, no less) is quite impressive.

Check it out:

http://www.buddyknavery.com/