You may recall my post last month titled File Formats for Conversion to XAML. In that post, I asked which formats make the most sense for conversion to XAML for use in WPF applications. In addition to the blog feedback, I've received a lot of e-mail, and I've heard from fellow Microsoft employees who are working with our early adopters. Among the 2D requests, Adobe/Macromedia's Flash format comes up quite frequently. So, I decided to use some spare time to investigate what kind of effort it would take to convert SWF files to WPF/XAML.
A few searches quickly turned up A Concise Guide to the SWF File Format and Alexis' SWF Reference; both are very useful references. The SWF file format employs some unique bit field types that make parsing the file—how shall I say—interesting. Fortunately, I used to work with stuff like this all the time, so it didn't take too long before I had written a handy BitReader class to make life a lot easier. Perhaps I'll use it as the subject of a future post.
The SWF file format contains a number of tags that either define data or control the data that has already been defined. It's the combination and order of these tags that allow the SWF file to represent shapes and other assets that move over time. Although it's not the subject of this post, animation in the SWF file is frame-based. That is, shapes are first defined and then placed on the display using transformations. Then, the machine waits the period of a single frame, and the next set of tags is processed to transform existing assets such that, over the course of time, movement is achieved. To convert SWF frame-based animation to WPF timeline-based animation looks like it will require some inference. More on that later.
For the DefineShape tags, geometry is represented in a way that makes conversion to individual WPF elements a bit tricky. Although the diagram below may appear to be an orange rectangle on a layer above a blue rectangle, in fact, this is a single defined shape in the SWF file, and what appears to be an obscured area of blue doesn't actually exist at all. I'll use this compound shape to illustrate how the SWF file stores its geometry. I'd recommend that you consult one of the aforementioned resources if you want to know all of the detail. For my purposes, I'm going to gloss over some of the detail so that I can focus how this is relevant to WPF.
As you may know, geometry in WPF can be stroked (outlined) and filled using a variety of different brush types. However, any geometric shape can only have a single stroke type and a single fill type. If we were to represent the rectangles below in WPF, because of the two different solid-colored fill types (blue and orange), it would require two shapes. We'll come back to this.
When a shape is defined in the SWF file, the first thing that's defined is its line (stroke) styles and fill styles. For the shape below, there are no line styles, and the two fill styles are solid blue and solid orange. Following the styles, a setup record selects which line style and fill styles will be used to draw. Because the SWF format specifies that any line segment can have a fill color to its left and to its right, you can imagine the setup record as saying something like: "grab this pen, and dip my left-side brush in this paint and my right-side brush in this other paint." What follows is then a series of straight or curved line segments referred to as edges.
For the shape above, I've listed its edges in a table to the right. Each edge segment is listed with corresponding left and right fill styles. Although they don't appear in this list, there are setup records before the first AB segment (to "dip" the right brush in solid blue), before the EF segment (to dip the right brush in solid orange), and before the AI segment (to dip the left brush in solid blue). If you follow each segment in the diagram, you can see how the right and left fill styles correspond to the final shape. Note that the segments in my example are conveniently connected to each other in the order that they're listed. Although I haven't run across it yet in any of my sample files, the file specification documents above indicate that segments can appear in almost any order, so prepare for this.
Here's the general algorithm that I use. When I encounter an edge segment, I add it to an array of segments that includes its start and end points along with the current line style and the fill style to its right (choosing to store the right fill style was completely arbitrary on my part...similar logic would work if you chose to use the left fill style). For segments that only have a left fill style (none in my example), I swap the start and end points, which effectively flips the segment and allows me to convert a left fill style into a right fill style. For segments that have both left and right fill styles, I add two segments to the array: one with the normal right fill style, and a flipped segment with the left fill style converted to a right fill style. For example, when I read the AI segment for the shape above, I store two segments:
After the segments have been collected, I take all segments with the same line style and right fill style and consider them part of the same figure (note that this can result in disjoint geometry). Then, for each figure, I run an algorithm that connects segment end points to start points and references them using a linked list. I'm sure I can find a faster algorithm to accomplish this last step, but for testing, the naïve method works just fine. As I mentioned, you may end up with some disjoint geometry in your figures. For example, imagine a single shape that contains two non-intersecting rectangles with the same line style and fill style. So, when you spit out your WPF geometry, don't assume that each figure only has a single starting segment (i.e. a segment with no prior segment).
I'm sure there are cases that I haven't encountered yet, and frankly, my current investigations are only so that I can appreciate the scope of the problem. Fortunately, once you have code that reads DefineShape tags properly, it appears that you've also done most of the hard work for parsing character shapes too.
Beyond shapes, media, transformations, linear and radial gradients, and clipping, animation looks to be the next challenge. Because of the frame-based nature of data in a SWF file, I imagine that it'll be a bit more difficult to infer the original timeline-based intent of the animator. However, I'm confident that this can be done, because products like Eltima's SWF to FLA Converter have to perform similar logic.
For the truly ambitious, converting ActionScript to something like C# would be the final step. I haven't gone this far in my investigation, but I'm sure that someone out there can do it.
Is it you?
I've spent over 26 years writing software. In that time, I've authored many programs that interact with hardware and external devices. But, it has been a long time since I've worked directly with microcontrollers, and even the little experience I've had has been very limited.
Some time before the New Year, a user group friend from Michigan asked me if I had any recommendations for learning microcontroller programming. While responding to his e-mail query, I was reminded of Parallax, Inc., a company I'd run across in my past. So, I spent some time digging through their site and many others and decided to put one of the Parallax starter kits on my Christmas list. I was thrilled when I ripped open one of the gifts from my dad and his wife Terri: a brand new BASIC Stamp Discovery Kit!
I won't go into all the details, because you can find a lot of great information on the Parallax site, and I'd encourage you to spend some time there. The kit includes an excellent 333-page introductory book called What's a Microcontroller that was written specifically for the Parallax starter kit hardware. The book starts by covering the basics of a microcontroller, helps you install and configure their computer-based IDE, and by page 24, you've already written the canonical "hello world" program that sends debug information via serial/USB back to their IDE. Pretty cool stuff.
Step-by-step, the well-written text leads you through lessons that carefully build your knowledge. Don't worry if you've never taken an electronics class. The text covers just enough to gain a basic but working understanding of the circuits that you're constructing. The starter kit includes all of the electronic components you'll need (resistors, buttons, LEDs, servos, etc.) to work through all ten chapters. You'll start with blinking LEDs, add buttons, control servos, connect a 7-segment display, measure light with photoresistors, create sounds with a speaker, and integrate of lot of the learning into a final project. I'm about two-thirds of the way through the book, and I'm having a blast.
The kit includes a 500-page BASIC Stamp Syntax and Reference Manual, and if you've ever written anything in BASIC, you'll be productive immediately (they call their variant PBASIC). I'd love to program this thing using a modern language like C#, but frankly, PBASIC is a breeze, and it's more than adequate for programming their microcontroller. If you've never used BASIC before, you'll have no problem learning as you go. The author has integrated the language education seamlessly with the rest of the text.
Of course, if you want to take your learning even further, Parallax provides projects and kits that increase in complexity all the way up to building your own sophisticated robot. If you do decide to dive-in and purchase the BASIC Stamp Discovery Kit, I'd recommend the recently-available USB version, and be sure to order the 9V DV Power Supply. It'll make your life a lot easier.
Have you ever wondered how various transmission speeds relate to each other? Or have you ever stopped to consider how USB 2.0 compares to Fast Ethernet? I frequently encounter people—even technical people—who don't seem to get it. I was listening to a podcast (to remain unnamed) just yesterday where the participants were reviewing a portable audio/video device. After commenting that the device supported both USB 2.0 and Firewire connections and noting the relatively large size of video files, one of the speakers ranted: "but I wish it had an Ethernet port." To which I mentally responded: "why...so you can transmit your data at one fifth the speed!?!?" The clear implication was that an Ethernet connection would provide the faster solution.
I also get grief from people because I almost always plug a network cable into the back of my laptop, even if I'm in wireless range. I'll grant that a wireless connection is the ultimate in convenience, and it's often good enough to be faster than your broadband connection at home, but if you're transferring files of any size, let me be the first to tell you that wireless will almost always lose against a standard Fast Ethernet connection. It's important to point out that there's a big difference between theoretical and actual transmission speeds. In the case of a wireless connection, achieving 50% of the theoretical maximum is quite common, especially in a congested area. That means that if you're running 802.11b, you may be limiting yourself to 5Mbps (of course, your mileage may vary). So, if you have an 8Mbps broadband connection to the internet, your wireless connection becomes the bottleneck.
If you don't believe me, I encourage you to copy a large set of files over your wireless connection, then try the same experiment over a wired connection. You won't need the precision of a stopwatch for your test. Chances are extremely good that you'll see a very noticeable speed difference without doing any measurements. I like to think of it this way: wireless = convenience; wired = speed. By the way, if you are in a congested area and you're a relatively technical person, I'd recommend re-running this same test for each of the available transmission channels on your wireless access point. You should be able to find a channel that provides you with less interference and that results in faster transfers.
I've put together a quick chart that compares the theoretical maximum transmission speeds of some common technologies. All of the speeds are measured in Mbps, which is megabits per second. I only mention this because I've seen many people confuse Mbps and MBps. Lower-case "b" means "bits," and upper-case "B" means "bytes." Click on the chart for a larger version.
Want to win a free trip to our upcoming MIX 06 conference in Las Vegas and a very cool custom Xbox 360? Well, if you're a CSS guru, enter the Remix MIX contest. Redesign the MIX 06 site with your own custom CSS, enter it into the contest, and it'll be judged based on a number of factors including overall design, creativity, and popularity. Three winners will be chosen. If you're looking for inspiration, check out the gallery. Good luck!
In his MSDN TV 15-minute video, Mike Henderlight talks about "Crossbow," the code name for the technology that allows Windows Presentation Foundation controls to work with Window Forms, and vice versa. Unless you're writing a brand new application to take full advantage of WPF, it's likely that you'll begin to include more powerful WPF controls in your Windows Forms applications as you migrate them over time. Or, you'll use your favorite Windows Forms controls to add functionality that doesn't yet exist in WPF. Either way, it's good stuff to be aware of. Read more in the Dr. Dobb's interview, Windows Presentation Foundation Interoperability.
The good folks at Mobiform Software (makers of the Aurora XAML designer for WPF) have put together a two-day class that introduces students to WPF programming and XAML. The course is taught by Ron DeSerranno, Mobiform's President and CEO, in Vancouver, Canada. Looks like the next class is coming up on March 6th and 7th. Register here.
Jelle Druyts has authored a useful MSDN article called The Command Pattern In Windows Presentation Foundation (via Rob Relyea). In it, Jelle explains how the classic Command pattern has been baked directly into WPF. And although it's a bit older, Ian Griffiths' article on the subject is also worth reviewing.