Robin Debreuil's Blog

Horrible IDE experience with otherwise reasonable IntelliJ

Robin Debreuil — Sun, 30 Mar 2008 07:43:00 GMT

I've been looking for something good to edit JSFL with, and tried out IntelliJ. Firstly the IDE is pretty nice, no question. You can't alt select columns, and dragging text is very flakey (my two favorite things), but other than that is seems very solid. Tons of refactoring for Java in there if that is what you are doing. The Javascript support is reasonable, as far as JS goes anyway (code sense is a hard problem in JS - I helped with that at Aptana so I'm pretty lenient there : ).

The bad thing is actually from a combo of 'enhanced' behaviours. First, Redo is ctrl/shift/Z rather than the more standard on Windows ctrl Y (Adobe, MS..). I'm a long time Corel IDE fan (also ctrl/shift/Z), so that isn't a problem. The problem is ctrl Y is mapped to something destructive -- delete current line! Once in a while I will want to copy something from an hour ago, so I will hold down Ctrl Z until I'm sure I'm at a point where the old version has the code I'm interested in, then *carefully* find it and maybe copy it. Then I hold down Ctrl Y until I'm all the way back. I'm sure you can guess what happened - went back over a lot of hard earned JSFL code, then held down ctrl Y, which is delete line (an edit). The text flickers in this mode, so it took me a minute to figure out what was up.

Ok, at this point your doc is seriously screwed up, you are afraid, and you are wondering what best to do. I gingerly closed the document (after all I hadn't saved), and got the hell out of IntelliJ. When you meet a bear in the woods, just drop your pack and back away slowly. To my very big surprise when I opened the 16k file in TextPad (hmm, wasn't that 20k? well whatever), I realize intelliJ saves your file on every single edit. Well isn't that fucking clever. I'm all for thinking outside the box, but rule one of an IDE is don't pooch the user data. If something as common as redo is remapped, the old default shouldn't be the total opposite of what you wanted there. And if you save every keystroke, you should make a backup somewhere between regular saves, that is obvious to find.

It is a good IDE, but Javascript isn't so much fun that I'd pay $250 to have it destroyed by my muscle memory.

(And for the record, I haven't worked at Aptana for a while -- I was using intelliJ because it seems Aptana didn't get near the code completion I remember it getting. So this isn't a ra ra thing, it is just a big hairy complaint).

reading and writing bitmap fills in JSFL - a solution

Robin Debreuil — Sat, 29 Mar 2008 06:28:00 GMT

I've been doing a boat load of JSFL recently for this Sesame project (50,000 assets will drive anyone to JSFL). One of the things that always bothered me in JSFL though, was the inability to manipulate bitmap fills. That may not seem like a big deal, however it is *the one thing* that prevents accurate document transformation/recreation. I made a tool 'sel2Draw' a few years back for a devnet cd, where you could select an object on the stage, and it would convert it all to code. It could do everything *but* bitmap fills. So it worked ok, but if you wanted to use it for anything automated you couldn't trust it. Yes, a toy.

Completeness is really important for this current side project, so I decided to do the dirty. I was about half way through hooking up the swfParser/Generator lib (from theConverted) to get the info from an exported swf (yuck). Getting that and matching it up, even with the tools, is tricky -- and you end up with a lot of new problems. Besides, it is just ugly, and I mean that in the bad sense of the word. About half way through though, I realized there was enough info to get bitmap fills from JSFL alone! It is actually pretty straight forward in the end, not sure why I didn't get this last time. I did hook it all up to sel2Draw, and sure enough it worked : ).

By paragraph three, you really need to get to the point. The way sel2Draw gets colors, is it converts the vectors into closed rings, and then tests the inside of those rings by making a small selection. You can then call getCustomFill on the selection (not to trivialize, getting the rings and knowing where to sample is actually a fairly hard problem). So if this sample is a bitmapFill, you will get back 'red solid fill' from JSFL (bitmap fills are red underneath, as you can see when you accidentally delete a bitmap from the library). So solid red color is the flag that tells you when you need to test for a bitmap fill. All you have to do here is paste your little selection in a new document, then check that doc's library. It will either be empty (which means it was an actual red fill), or the new library will have a single bitmap, which will have the same name as the bitmap fill used in your fill! The original solid red fill will still have a matrix, and that is the bmpFill matrix.

To recreate that fill, place the bitmap of the same name somewhere on to a blank peice of stage. Then apply the matrix to it, and break it apart (in that order). Sample this the same way (selection, getCustomFill), delete this temp object, and then fill your real object with the current fill (make sure the fill is locked). And that is all there is to do : ).

Here is some temp code I was using, it assumes a single unicolor selection. Obviously you could make it more efficient, eg, I use a single scratch doc that keeps getting cleaned out for this for the whole parse, etc... In any case, this is the jist...

    else if(foundFill.style == "solid")
    {   
        var colString = foundFill.color.substring(1,8);
        foundString = "[0x" + colString + "]";
        var bmpFill = "";
        if(colString.toLowerCase() == "ff0000")
        {
            // might be bitmap fill
            curDoc.clipCopy();
            var testDoc = fl.createDocument();
            testDoc.clipPaste();
            
            for (var i = 0; i < testDoc.library.items.length; i++) 
            {
                var itm = testDoc.library.items[i];
                if (itm.itemType == "bitmap") 
                {           
                    bmpFill = itm.name;
                    break;
                }
            }
            fl.closeDocument(testDoc, false);
            trace("bmpFill: " + bmpFill);
        }
    }

Weirdest VS2008/.Net3.0 bug...

Robin Debreuil — Wed, 26 Mar 2008 01:16:00 GMT

I'm running a dll from .net 2.0, and it runs fine. I load it into a .Net 3.0 program, and boom it fails --- on a basic switch statement it takes the wrong branch. I can set breakpoints, verify values/equality in the immediate window, all is fine. It just chooses to run the wrong branch. Very disturbing.

For the record here is the code that is failing, maybe I'm just not spotting something obvious.

switch (curTag) // value is TagType.RemoveObject2
{
	case TagType.RemoveObject: // *** takes this branch
		ControlTags.Add(new RemoveObjectTag(r)); 
		break;

	case TagType.RemoveObject2:
		ControlTags.Add(new RemoveObject2Tag(r));
		break;
		
// from the immediate window:

curTag == TagType.RemoveObject
false
(int)curTag
28
(int)TagType.RemoveObject2
28
(int)TagType.RemoveObject
5
curTag == TagType.RemoveObject2
true

Not sure what to say here, I keep thinking it is something stupid, but it is the same dll both times (runs fine from a .net 2.0 program that refs the same dll, and parses the same swf file, and even uses the same code to do that). Maybe they just aren't meant to run together? Hmm...

PhillipK explains why you might need different technolgies in a nice non technical way

Robin Debreuil — Sat, 23 Feb 2008 12:05:00 GMT

http://www.youtube.com/profile_videos?user=phillipk&search_query=30onair&search=Search

Sky and Free's awesome XNA game - YouTube video

Robin Debreuil — Thu, 21 Feb 2008 17:31:00 GMT

Sometimes people ask me if I helped - I didn't, and quite honestly I couldn't do a lot of that shader madness even if they wanted help : ). My Grandma bought me my first computer (a Vic-20) when I was exactly 15, so I guess they have a head start. Still...

http://www.youtube.com/watch?v=nTj-Q5i9yuM

Fix for Annoying Mac (Flash) Projector Bug

Robin Debreuil — Mon, 07 Jan 2008 00:21:00 GMT

This bug has been a big problem in a project I'm currently on (Kid's game CD's), and I haven't seen a fix online so I thought I should post this (at least for myself as I'll forget : ).

When creating a custom cursor, you need to hide the existing arrow cursor -- Mouse.hide() works fine. However, in projectors (mac and win), when you right click and get the dialog, the cursor reappears. Ok, this is probably a bug, but you can just listen for a mouse up, and rehide the arrow cursor. However, on that Mac projector, this doesn't work. If you call hide again, even a million times in a row, the arrow is still visible, and exists over top whatever custom cursor you've made.

It ends up it will work if you call show again before calling hide. I suspect that there is something in there trying to be too smart - checking some internally set state that keeps track of cursor visibility, seeing that it is already invisible, and not bothering to make it invisible. That is probably out of whack due to the bug on right click. As a general rule I always try to run things like that anyway (when running them twice has no effect). If that isn't possible, then at least I try to check the state as close to home as possible (which in this case would be asking the OS). Of course that may well not be possible in this case, who knows.

I can't believe I've gotten this far without cursing the stupid mandatory right click dialog, that is my all time most hated thing about Flash. I don't care if it is hard, or even costly, sometimes you really really don't want to have that. At very least, it shouldn't also cause extra bugs, yuck.

Anyway, got my rant in, here is some code. The updateAfterEvent probably isn't needed, I was just being superstitious (it does cause an occasional slight arrow flicker - my mac is in the house or I'd test).

Mouse.hide();
var rcListener:Object = {};
rcListener.onMouseUp = function()
{
   Mouse.show();
   updateAfterEvent();
   Mouse.hide();
}
Mouse.addListener(rcListener);

Adobe copying MS!

Robin Debreuil — Sun, 25 Nov 2007 13:59:00 GMT

I can't believe Adobe would so blatantly copy MS on this (ok this is a joke, my last post said the opposite, I was wrong, and just trying to be fair and balanced here!):

http://www.microsoft.com/presspass/press/2004/oct04/10-05msacrossamericapr.mspx
http://onair.adobe.com/blogs/onair/category/onair2007/

For the record, MS has done the road trip before : ).

One good road trip deserves another, I guess

Robin Debreuil — Fri, 09 Nov 2007 02:40:00 GMT

Edit: Oops, one more link: http://www.microsoft.com/presspass/press/2004/oct04/10-05msacrossamericapr.mspx

Ok, I'm an idiot, ignore this post : )

1) http://onair.adobe.com/blogs/onair/category/onair2007/

2) http://thecodetrip.com/

So is this something software companies do a lot? The first I heard of it was the Adobe one, but maybe it this has been happening over and over, and the buses never make it to Manitoba... If it is just a straight copy, man, first they have PDF Envy with XPS (I looked that name up btw), then Flash envy with Silverlight, and now it seems even bus trip envy. So what is next, hairstyles? Finding out what these people name their pets?

"Man, if we only had a public faced tech guy with a little grey streak on the front of his hair, oh and a blogger named John that sometimes wore a cowboy-ish hat... What else, well looky here, we need to rename fluffy to BlingThing-- doh, that is it -- now Silverlight will take off like a rocket!"

Ok, or more likely someone wanted a good road trip, and who can question pure heart motivation like that... PS, Mantioba is up from North Dakota, stop by for all the hot chocolate you can hold : ).

StandOut public beta from Electric Rain - you have to try this!

Robin Debreuil — Mon, 15 Oct 2007 15:03:00 GMT

I was lucky enough to get a demo of this, and be on the beta list. It is from the good folks at Electric Rain, the makers of Swfit3D and more.

People complain there isn't enough innovation in software, and frankly they are right. But! But StandOut is packed with new ideas, it really makes you rethink things. One example is "flypaper" - you know that space that wasted background grey space when you have two or three windows opened. You have to check out what they've done with it, not just used, but very cleverly. I'm looking around for wasted pixels all the time now : ).

Lots more in there, cool UI, what can I say, check it out! Oh, and expect presentations to be a little less boring in the future : ).

http://www.erain.com/products/standout/publicbeta/

Free swf dump tool available for download

Robin Debreuil — Fri, 05 Oct 2007 02:19:00 GMT

Ever wanted to see the guts of a swf file? There have been a few very nice swf dump tools released over the years, here is another one : ). This supports up to v8 (for now), and the actions are dumped as flasm code.

I didn't bother putting switches in, so it is pretty verbose. If there is *any* interest at all I'd be happy to add them. I've been using it 'as is' for the last while -- too lazy to do it right for just myself I guess : ).

swfdump (82k)

usage:

swfdump filename

There are a few things I'm not fully dumping yet, I'll update when they are added. In spite of that though, if you see a bug, I'd be happy to know about it : ).

Japan, Petzold, and Triangles

Robin Debreuil — Wed, 03 Oct 2007 01:12:00 GMT

It has been a busy summer! We were in Japan for August (and man was that nice or what!), then we spent most of September moving and settling in to the new farm (and man is this nice or what!). That being that, it has been a bad summer for blogging, I have a number of posts I hope to make in the next little while. Hopefully it will be like when Mitch Hedberg pinches the microphone cord -- he lets go and a whole bunch of jokes come out...

I've been reading a great book by Charles Petzold:

3D Programming for Windows: Three-Dimensional Graphics Programming for the Windows Presentation Foundation

I'll post a fuller review once I'm fully through it, but the great thing about all his xaml books is he starts using code and builds from there to markup. Imo Xaml is 99% useless, but at its heart it is at least the new GDI. If you know your way around it in code, you can either ignore the markup, or use it and not be pissed off every time you 'compile'. So this is what makes his Xaml book not just good, but actually essential.

The man has a friggin Windows tattoo. That was a shock. And still a great book.

But first up, in Japan I was working on and off on triangulation to display vectors in directX. It was intensely hot. The long and short of it is A) Converting that stuff efficiently is fairly tedious, but interesting (is that even possible, to be both?), and B) there are a lot of triangles in a typical Flash vector drawing. Like 4 tons of triangles per square inch. I don't think it will even work for the default approach, where curves are 'curve fitted' using lots of little triangles. ZMan was kind enough to send me a link to a very interesting approach from MS Research I've done a few tests, tried a few ideas that didn't work, and this seems like the best approach I've seen so far.

Also while in Japan, I found a body... I guess not everyone is happy. I'm not sure why that is so surprising, but there it is. I'm really sorry that is true.

Here is the code. The code really looks like it bubbled up during a one month on and off sloppy experimentation extravaganza in 40 degree humidity. In fact it is. Worse, it isn't even finished. But it really is almost finished (just need one more segment add routine, but I'm all busy doing swf action code stuff. Oh and need to clean up, aka start over -- but it is the thought that counts right?). That being said, here it is:

Le Code

Zoom in and out with the A-Z keys, arrows for direction. To get the other xaml files to run (in Game1.cs), you have to disable hull removal (the part that isn't finished). That is the RemoveToSegment method, on line 243 of Delauany.cs. I'll try to finish it up, and convert it to something useable, and post again. Did I mention it is messy?

Btw, if you are interested in this stuff, there is but one starting point on the web, and that is this page: Jonathan Shewchuk is the guy

Ok, who can resist a screen shot? The mighty letter R.

Ok, what were you expecting then?

theConverted gets Swf to Silverlight support, a Symbol Viewer, and a New Low Price!

Robin Debreuil — Mon, 27 Aug 2007 12:05:00 GMT

There have been a number of advances made with the Swf to Xaml converter recently. Firstly due to some great feedback there have been a large number of fixes, features, and optimizations. Secondly there is now an additional UI, a 'symbol viewer'. This allows viewing each symbol in the SWF file, in both WPF and Silverlight versions of Xaml. What? Silverlight?? Yes, due to numerous requests, we've added support for Silverlight verison 1.0. There is a limit to what can be done here due to current limitations with the format, but much of that should be rectified by version 1.1 which is on the horizon (which of course we will also support when it is released).

Lastly, a brand spanking new low price of $48.00. Yeow! We have code support on the way, and XNA (directX) support is coming along nicely (now triangulating, yeaay!). We would really like to give this a push in anticipation of these new tools folding into the product. Oh, a purchase includes a year of upgrades, so no need to wait ; ).

theConverted.ca

Voronoi Diagrams, Triangulation, and More Pixel Shader Pictures

Robin Debreuil — Fri, 27 Jul 2007 07:18:00 GMT

So it has been all triangulation research for the last few days. I have a few working test programs (for converting vectors to triangles for GPU consumption), and I've been just fooling around with the math a bit too. I was/am interested in trying to get the GPU to help with Delaunay triangulation and subsequent mesh optimizations.

The file below makes pixel shader animations based on voronoi diagrams, which means every pixel is the color of the closest dot. Others do weighted voronoi, which means some pixels have more 'gravity' than others, and most add a few things to make them look interesting. The last two show simple "local feature size" (lfs) which is the distance to the two closest non-touching segments or vertexes. All of this stuff is very useful when deciding where to insert vertexes to get 'nice' triangulation (aka, larger angles, larger triangles, smoother transitions to big and small, etc).

Well here it is, as usual hitting the space bar will advance to the next animation. And editing/tweaking your own is fun and easy : ).

Download

Updated Trial version of Swf to Xaml converter

Robin Debreuil — Thu, 26 Jul 2007 16:13:00 GMT

There have been a number of fixes to the swf to xaml converter:

Some fonts were causing a crash, fixed.
Font spacing wasn't supported, things like center text were affected, fixed
Alpha that was reused per frame was forgotten, fixed
Movieclip placement issues, there were a few (mcs are only able to be poorly simulated in xaml) - many fixed, but not all.
Buttons are not supported yet, but are safely skipped
Support for files that do not have continuous indexes (like after optimization)
Some masking issues fixed
A fair bit of tiny things that I can't remember atm, totally fixed : )

Download is available through the site, or directly from here:

http://theconverted.ca/trial/TheConvertedTrial.zip

Your Computer on Drugs

Robin Debreuil — Fri, 20 Jul 2007 13:52:00 GMT

I'm really not sure of the history, but pixel shaders must have been invented in the 60's. One of the things that has always drawn me to computer programming is the ease in which you can make cheezy gratuitous math based graphics. With pixel shaders it is like you have a brand new Commodore 64 all over again.

I've modified the bouncing circles program (all shader no triangle) to select different shaders using the space bar (download here), but the real fun comes when tweaking the code yourself. Especially when combing things, and more so on multiple passes. These basically get the distance between each moving point, and then do some math, always truncating the result to be between Zero and One.

Here are a few points of interest I've been stumbling over... Optimizing is really unintuitive - hard stuff (distance, matrix manipulation, trig, etc) tends to be really fast as it is mostly hardware. But then easy stuff (like if/else) can be very slow. At least for shader 2, there is no flow control - it is simulated by running both paths and then nullifying one. So at one point I tried to optimize things by throwing out circles that were too far, and it totally slowed down! So switching between effects is much faster if you have 20 different effects, rather than one effect and an index (say like a switch statement equivalent in your pixel shader).

In spite of these cards being able to do floating point math like a hungry animal, it is still going to be tricky to do Flash style animation. I was thinking potentially some kind of ray tracing technique on to optimized bezier data, but seems like it will be too slow. Then the brute force triangulation seems like it will have too many triangles (an outlined donut took 300+ triangles to look reasonable full screen - compare that to a swf with 100s of much more complex shapes and tricky fills).

I am thinking one way to get around the jaggeds would be to use a static number of vertexes per shape, and as it zooms in (and part goes off screen), reuse the unseen vertexes in the visible area. This would require recomputing the locations, but that could be done in the vertex shader if the vertex count is constant. That being said, it still requires a large number of points, so you would probably have to reset the point count based on zoom and complexity. Ideally you could say, here is your frame, use the 500,000 vertexes you already have to render it. Maybe that means 500,000 vertexes in a buffer that doesn't change, maybe upload new indicies when things change radically, and only your draw calls happen every frame. Eg. you have 2 circles of 30 vertexes each, then change them to 3 circles or 20 vertexes each - same vertexes and maybe same index buffer, just three calls to draw triangle fan, as opposed to two calls. Hmm, anyway, lots of testing ahead.

Well, here is the download if you want to waste some time, requires Pixel shader 3 on your card (new-ish) and the XNA runtime stuff.

Download

Pixel Shader Animation -- some idea of performance

Robin Debreuil — Thu, 19 Jul 2007 05:34:00 GMT

So some more testing tonight. To get some idea of what it takes to choke a pixel shader, we made a bunch of animated circles. There is again only two triangles here (which draw the the background), and all animation/rendering is done by checking the x,y of a pixel against some set of data, and rendering its color accordingly.

In this case the data is a bunch of animation 2D points, and the formula checks if the distance from its pixel to one of the points is within a certain bounds (using distance, ouch). If it is close enough it flips the color, if not it leaves it alone. This creates a bunch of bouncing circles.

float4 CircleShader (VertexToPixel PSIn) : Color0
{
    float4 result = PSIn.Color;
    float dist = 0.05f;

    for(int i = 0; i < circleCount; i++)
    {
        if( distance(points[i], PSIn.TexCoord) < dist)
        {
             result =  1.0f - result;
        }
    }
    return result;
}

First, let me just say in spite of this choking after about 20 circles, it is a-m-a-z-i-n-g the amount of grief you can send at a video card without a hiccup. This formula is run on every pixel on the screen, going over every point in the array, many times a second. Alas all good things have limits, and at first blush it seems the limit for this technique will be well short of Flash style animation.

ZMan sent along a very interesting link, to a paper from MS labs where they are still using triangles, but they are based on quadratic bezier data, and the edges are 'rounded' to fit the curves. This seems somewhat more hopeful, but I'd still like to at least do a brickout game or something with this technique : ).

Download sample project


Works like a champ.	Chokes like a bastard.

Simulating 2D Animation in DirectX/XNA

Robin Debreuil — Wed, 18 Jul 2007 03:53:00 GMT

I've been mulling over how to approach converting Vex to XNA. Vex is the interm format between the Swf to Xaml converter, basically a 2D animation format. Going to Xna would therefore allow converting swf/gdi/xaml to DirectX or Xna for use in Video games, or any other general purpose hardware accelerated 2D animation. I have a feeling this could be very fast, but there are potential bottlenecks too.

Note: GPU's can only create triangles. To create smooth curves, you need a lot of triangles. A lot.

The first thought is to just convert each Line into triangle strips, and each fill into whatever triangles will fill the shape in question. I'm sure this would/will work ok, but there does seem to be the potential of sending an awful lot of triangles every frame! In shader 3 cards (which are pretty new ones) you still can't create vertexes on the card (you can do this in shader 4, but you can't count on people having that at home for a while, not to mention on the xbox360). So if you can't create vertexes, you have to create all the triangles with CPU, then upload them to the GPU, mostly every frame. As you wind over curves and fills, that can really add up. Maybe not to the limit of the card (not sure), but it still really bugs me.

Note: Shaders are basically simple functions that run, in parallel, on up to hundreds on mini CPU's at once. Pixel shaders run a function once for every rendered pixel on the screen.

So an alternate idea we started testing today was to keep bezier points, and put them in nicely sorted trees. Then add only two triangles (to make a rectangle screen) to draw on. All graphics are then created with a pixel shader. The idea would be that each pixel would look up what color it is supposed to be from the tree. That is a bit wasteful compared with line scan etc, but because it is parallel and all done it hardware, it seems it would be plenty fast. Also it is all done on the GPU, freeing up the CPU and the lines of communication. And maybe it just feels cleaner.

Anyway, with a little help from Sky and Free, we got a test file going (yeah, I'm no shader guru, here are some awesome tutorials btw). It isn't using real beziers yet, its more for seeing how it looks, how the code looks, and how it performs. Seems ok so far, the trick will be getting a good file format, and an efficient lookup. There is a screenshot below (this is an animated sample btw), but feel free to download the code and tweak it yourself. Requires all the usual (free) XNA dev tools.

Download sample project

Updated Trial version of theConverted

Robin Debreuil — Wed, 18 Jul 2007 01:40:00 GMT

There is a new version of the SwfToXaml converter up. There were some issues with tags not yet supported (like buttons, still not supported, but handled now), as well as issues with certain types of Movieclips.

Direct link to new trial version

- Movieclips that do not have an inital matrix are now handled properly
- Swfs that have tags out of order are now handled properly (not sure where these come from, maybe optimization software).
- Tags that aren't supported shouldn't crash anything - well I guess that is self evident, but some were : ).
- Added support for some ancient swf 3 tags, like anyone noticed that one.

Upcoming

We are a few steps further on code support. We will also be adding a Blend compatibility mode, it generates xaml that is a fair bit more verbose, but you can view and scrub animations in Blend. We are also hoping to cut down filesize somewhat with the use of Styles. Adam Kinney and Tim Heuer have had some great and much appreciated advice on the generated Xaml. The above and more, hope to get it all in soon!

PS The forum going up was my usual html fiasco, I spelled FORUM as FOURM, then changed it all and uploaded (I swear I did! Really!) --but the update didn't seem to take. Making matters worse, I thought I blocked comments from non members (aka spammers), but instead blocked viewing from non members. Ugh. So anyway, the real url is:
http://theconverted.ca/forum/
Not that there is anything going on there yet, just feel free to post if you are having questions or problems.

Cheers!

Bought a farm...

Robin Debreuil — Fri, 13 Jul 2007 01:02:00 GMT

We finally found the farm we have always been looking for, and signed the deal today. It is a small acreage of mostly popular and saskatoons (berries). There is about 10 acres of cultivated land, 40 acres of trees, and 5 acres of yard. Lots of deer and wild turkeys, a number of out buildings, and a great garden. Well what can I say, we are all really happy : ).

There are some pictures below, and a google maps view as well. If you are in the area after September, please drop in : ).

The new farm

New Swf/Xaml Forum up

Robin Debreuil — Thu, 12 Jul 2007 03:00:00 GMT

We've put up a forum that we hope can be useful to people moving in and out of the swf/xaml, actionscript/.Net worlds. Well maybe useful one day, right now it is pretty much empty : ). It is also a support area for our swf to xaml conversion tool, but don't be shy to ask/discuss things beyond that scope.

http://theconverted.ca/forum/