No, seriously. We’re very curious to see what kind of crazy ideas people can come up with. Check out this latest submission going wild with Kinect API and Away3D.

By the way, huge thanks goes to wonderfl.net for spreading the word free of charge:

we love Flash and Web developers community… so we’re gonna show your ads for Free (Masakazu Ohtsuka, KAYAC Inc)

Flash and Web developers, we at Code Orchestra love you too! And we hate when you waste your time compiling stuff. In fact, we hate it so much that next COLT release will build your projects up to 3 times faster (and we are talking both livecoding and production builds here). While these news are relevant to Windows users only, I’m sure there are lots of FlashDevelop users out there who will enjoy faster builds OOTB (if they install my COLT plugin).

<script name="" mod="9223372036854775806">
	<def id="avm2.intrinsics.iteration:hasnext"/>
	<def id="avm2.intrinsics.iteration:nextname"/>
	<def id="avm2.intrinsics.iteration:nextvalue"/>
	<def id="avm2.intrinsics.memory:lf32"/>
	<def id="avm2.intrinsics.memory:lf64"/>
	<def id="avm2.intrinsics.memory:li16"/>
	<def id="avm2.intrinsics.memory:li32"/>
	<def id="avm2.intrinsics.memory:li8"/>
	<def id="avm2.intrinsics.memory:sf32"/>
	<def id="avm2.intrinsics.memory:sf64"/>
	<def id="avm2.intrinsics.memory:si16"/>
	<def id="avm2.intrinsics.memory:si32"/>
	<def id="avm2.intrinsics.memory:si8"/>
	<def id="avm2.intrinsics.memory:sxi1"/>
	<def id="avm2.intrinsics.memory:sxi16"/>
	<def id="avm2.intrinsics.memory:sxi8"/>
	<dep id="Number" type="s"/>
	<dep id="int" type="s"/>
</script>

The solution is to remove any mentions of avm2.intrinsics.* from catalog.xml :) SWC continues to work without them for both ASC1 and ASC2. I asked Adobe people why does this garbage has to be there and break compatibility for no reason but got no reply, so I am posting this find as PSA – when some ASC2 SWC suddenly gives you headaches, you will know what to do.

Ok, now when we’re past this marketing part, let me continue to the reflection part. What kind of feedback we have received so far, and what can we learn from it?

Bugs

As any complex technology, COLT has to have bugs, and we’re happy to receive your bug reports. If you find bugs we missed, it means you are actually interested in and trying our product :) On our side of it, these bugs get fixed and new builds are uploaded.

But then, some “bugs” we hear about are not actually bugs, but inadequate expectations and failure to understand how COLT works. We are trying to extensively document this stuff, but there is always that user who says “k, I changed the code in enterFrame handler and it works, but then I changed the code in addedToStage handler and nothing happens“. So let me cover here again how does COLT work, real quick:

And this is all that COLT does for you. It does not magically know that you want some code to be executed unless your program actually says so. Sigh. This is not rocket science, is it.

Features

Another kind of feedback is that one can’t do that or that in COLT. That’s right. Features take time, and we wanted to release COLT ASAP so you guys could try it not next month but today, and maybe support the development with some warm words and cold cash :) Yet, we listen to you and add the features you want – for example with COLT 1.0.1 you can add new fields and methods to [Live] class! Now isn’t that great. But you know what is even greater?

You can get COLT license for free!

All you have to do is upload COLT demo or tutorial video to youtube before 25th of June. And if your video is really good, you get iPad4. And if your video is REALLY good, you get 15″ MacBook with retina display. Damn, I would record these videos like crazy if I were you :) Get the camera, get crazy idea and get it done, seriously. More here.

Good news for FlashDevelop fans

I have been working on this plugin to make FD work with COLT closer. It exports your FD project to COLT and, when you run that COLT project, sends any compilation errors back to FD. The plugin is WIP, but already does its job and I am working closely with Philippe to improve it. So, try it out, leave feedback on github.

That’s about it for tonight, I think, and hopefully more good stuff will follow next week.

We’re thrilled to offer the 260,000 active developers making great games and applications with Unity the opportunity to take advantage of the unprecedented reach of Adobe Flash Player across all major desktop browsers on more than a billion PCs… Unity developers will be able to take advantage of the stunning performance offered by the addition of hardware accelerated graphics rendering through Stage3D in Flash Player.

Oh wait, that was a year ago. Here’s what they actually said:

It’s been quite a while since we took a step back from our work here to give you all an update on how the Adobe Flash Player deployment add-on has been progressing. The good news is that things have been going great! We’ve had the chance to add in a lot of stuff that we initially didn’t think would be possible… We’re extremely proud of the work we’ve done making our engine the most powerful development pathway to Adobe Flash Player.

What, wrong quote again? Well, I guess I suck at quoting. So, let me just put the news in my own words: Unity executives compared costs to develop “the most powerful development pathway to Adobe Flash Player” with add-on sales and decided that it’s time to end it.

Oh yes, at the same time their “own Unity Web Player has seen unprecedented growth in recent months”, so they also decided it is good timing to blame Adobe and suggest everyone to move away from flash. Sounds like good decision to me, I mean it is working for them, right? Just look at all those tweets and posts they got in single day :)

What is it good for?

Adobe introduced these opcodes to implement memory access operations required by LLVM, so that Alchemy could do its thing, and Flash Player could run C++ code. But for AS3 people these opcodes did not do anything magical. It was just another way to read numbers from or write to one ByteArray at a time that, coincidentally, worked faster than IDataInput/IDataOutput. So, if you were to do some number crunching, it might save you some milliseconds.

The problem I have with this is that now, when ASNext is abandoned and AS3 performance is being surpassed by JavaScript, many people tend to bring up these opcodes as valid solution to *all* our “make AS3 faster” pleas. Just how exactly fast numeric array IO is supposed to help with complex data types known as classes? Good question.

Placing your class fields in domain memory

In C++ you have pointers, but in AS3 you don’t, so placing your class data there will be ugly. But, if you will be able to access them normally (via dot syntax) and faster at the same time, why not try it? So I did: using legacy compiler and azoth, I did this simple test, and… got domain memory based loop running over 50 times slower than plain AS3. WTF?? Turns out domain memory is only fast if you set your ByteArray to use LITTLE_ENDIAN order (it’s the opposite by default). With LITTLE_ENDIAN memory opcodes were about 10 times faster, but this was still not enough to bridge the gap caused by having to use getters and setters now instead of plain variable fields.

Enter the ASC2

ASC2 has two features that make it interesting in this case. First, it can inline method calls. Second, it can emit memory opcodes without 3rd party tools. So, after people reported that this was indeed working for my cause, I opened my FB 4.7 trial and went on to try that myself. I was confused a lot by the fact that none of memory opcodes were present in playerglobal.swc, but it turns out you can ignore that – the code will compile and run any way. This time everything went better than expected – I had domain memory based loop finally running 30 to 50% times faster, although timings fluctuated a lot update: I bumped arrays length to get better numbers on desktop; for MBP/Chrome/11.6 they were on average 220 ms vs 110 ms, for Windows/standalone/11.6 – 250 ms vs 190 ms. Finally, for iPad3/ipa-test/AIR 3.7 they were 200 ms vs 275 ms (memory opcodes loop was slower).

Apparat

People on twitter were fast to remind me that apparat had similar feature for quite some time. This way is probably the best way to use memory opcodes for people who cannot use ASC2. I wanted to include apparat-based test for this post, too, but it turns out I don’t have it installed here (nor do I have scala). It’s not that hard to install but, as lazy as I am, this is not something I am willing to do for the sake of this blog post. So you are going to have to trust in that it works, because clever people made it.

iOS support

Even though Adobe doesn’t think it’s important, there is increasing shift among AS3 developers to mobile, and Adobe’s AIR provides easiest way to do so. For months we were struggling to provide livecoding for iOS AIR apps, but there was always something in the way. This week, with great help of Nimisha, we’ve finally got it working there for the first time. Just check it out:

What I have here is simple painting app running on iPad with iOS v6. On the right, I edit its code in our CodeOrchestra IDE, and my changes get loaded into running app on the fly. Even better, my app does not get reloaded at all, and maintains its state! This is unlike anything you guys have experienced so far :)

“I’m sold, where’s the download link ?”

Well, it goes like this: CodeOrchestra IDE is not only about livecoding. It is big monster with a lot of tools, like AS3 to JS convertor for web and recently Node.JS, or domain specific language support allowing you to extend AS3 language itself. As such, there is a lot of stuff to test and a lot of bugs to fix, before it ships. So, to share this AS3 livecoding technology with you as soon as possible, it will be released in about a month as a separate product, that will work with whatever IDE you’re using right now. Please sit tight, we’re about to change the way you code forever :)

The scoop

Once you know how does the magic work, it is no longer magical. What happens here is every time you write new code, it gets compiled to small SWF file that then is loaded into main app’s ApplicationDomain. You can interact with new code naturally using your app logic, or you can subscribe to live updates event and do something special. There is no problem with this on the desktop, but iOS was the pain you know where. Because Apple is so paranoid about loading external code, Adobe had to simply turn this feature off in AIR, and there was nothing we could do about it, until AIR 3.5 beta came out with their “multiple SWFs” feature – suddenly it was possible to load SWFs on iOS. We were very excited about that, and were just about to release iOS livecoding demo, when Apple shot us down with their iOS v6 release, which made it impossible for us to drop new SWF files into running app folder. Since then we were contacting various people at Adobe and begging for workaround, but it was Nimisha who listened to us and, in the end, helped us to solve the issue. Were we more lucky, you’d see this post half of year ago. Any way, I’m happy we’re past this, finally.

In case you want to check more locations, click here.

Apple way

If you’re native iOS app developer, you are dealing with ecosystem that does support general purpose apps. You have simple CMDeviceMotion class that performs sensor data fusion, filtering, bias removal, etc, and gives you orientation data in any form you want (roll + pitch + yaw, or matrix, or quaternion). Case closed. The same class conveniently splits accelerometer data into gravity and user applied acceleration, btw. In a word, it’s perfect.

Adobe way

If you’re AIR app developer, prepare yourself – you’re going on the adventure. You can start by looking at flash.sensors package – for some mysterious reason, it has accelerometer API for desktop, but no gyroscope API for mobile. Why? Because Adobe does not feel obliged to include every piece of code you might think of in their runtime. But don’t give up your hope yet – Adobe has the solution for this kind of problems – AIR native extensions. And, it turns out that Adobe made one for you to access gyroscope data. Despite of being abandoned in 2011, apparently just before Adobe’s focus shift kicked in, this ANE still works with current AIR 3.x.

Okay, this is the part where you’re happy that you don’t have to write ANE yourself, and it seems that getting your hands on device orientation data is now only a matter of few additional build settings. Well…

This extension API, designed to be Accelerometer class twin, has two major problems in the way. Number one is that it only exposes raw gyroscope data, i.e. rotation rate. Since this is not something that flash developers do every day, you probably have no idea how to go from radians per second to orientation quaternion, or transformation matrix. So to use this ANE, you will have to learn some new tricks, such as finding approximate differential equation solutions, Taylor expansion of matrix functions, series summation and evaluating indeterminate forms. If you are still with me, good guy Oliver J. Woodman will guide you through this hell (pages 21 to 23).

Ok, now you’re done reading that and ready for action, right? Not so fast – there is problem number two. Let me just quote this comment from ANE source code:

// The singleton ExtensionContext object listens for StatusEvent events that
// the native implementation dispatches. These events contain the device’s
// gyroscope x,y,z data.
//
// However, each Gyroscope instance has its own interval timer. When the timer
// expires, the Gyroscope instance dispatches a GyroscopeEvent that contains
// the current x,y,z data.

Thank you, Adobe engineer, for this brilliant idea. Because there just can’t be enough lag or noise in my data. Sigh… so what do you do about this? You bypass ANE AS3 wrapper, and access its internal methods over low level interface. Of course, this means that you have to study both wrapper and native code beforehand :(

And here, my friend, we come to the end of our wonderful journey. I will go back to work on my AIR app, and you will maybe go and write your own ANE, with blackjack and hookers. Or you may choose to continue where I left off – maybe add Kalman filter or something. And don’t forget to write back, if you do :)

Faster processing

Much faster! New version still goes same old “replace the string everywhere in SWF” way, but it uses special charcode tree to replace all identifiers in single pass. I might write another post on subject, if there is enough interest.

Automatic identifiers collection

You no longer have to manually type identifiers that you want to replace. The obfuscator runs your SWF through as3commons parser and collects all identifiers; then you can remove identifiers that you don’t want to replace. Note that neither as3commons parser nor my wrapper code are perfect, so it will fail for some SWFs. You can send me those, if you want, but I may not be able to fix that after all.

Bulk filtering

You don’t want to rename stuff like beginBitmapFill, so I parsed playerglobal.swc v11.6 and made a checkbox to ignore all those identifiers. Did the same for apache flex then, but not sure if that’s useful – so that checkbox is off by default.

That’s about it. One last warning: there will be invalid SWFs, and there will be bugs. I can’t really fix them all, but if you send me your stuff I might try. Or not.