Posts Tagged 'flash'

How to make ASC2 alchemy SWC compatible with old compiler

Some time ago I tried to use latest Genome2D SWC with Code Orchestra livecoding tool and, like others, failed (at first). The reason was that COLT, being derived from old compiler, fails to parse SWC made with new compiler, if it uses memory opcodes. In theory, there should be no problem, since memory opcodes are already compiled into SWC’s library.swf and old compiler does not have to care about it. In practice, there is a problem in SWC’s catalog.xml:

<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"/>

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.


Code Orchestra Livecoding Tool update

Last time I have promised you standalone actionscript livecoding tool “in about a month”, and it was delivered in 1 month and 1 day. If some of you missed the news because I did not write a post about it here – don’t feel bad – because tonight brand new 1.0.1 build is waiting for you to download it :)

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?


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:

When you save your code, COLT compiles small swf file with parts that changed since last time; methods in [Live] class are changed to call the code in those small swf files every time.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.


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.

On unity flash add-on

Have you read what Unity guys just said about their flash add-on? Check it out:

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 :)

Don't be a parrot

Can AS3 and Alchemy be friends?

Ok, so many of us tried to use Alchemy opcodes in AS3 projects, years ago. But how many keep using it every day ever after? Not me. Why? Well, where do we start…

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).


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.

An update on Livecoding in ActionScript

Once upon a time, that famous Bret Victor talk hit the twitter and everyone went crazy about the idea for a week. Then everyone moved on, except few people around the world who set to create tools like that for web developers. Over the time, quite a few livecoding tools popped up, from LiveReload to recently Loom engine, but none for ActionScript. If you’re ActionScript developer, you should see why this kind of technology could not be developed overnight. AS3 VM is not really livecoding friendly, already loaded classes have priority over new stuff you load in. But, with enough efforts nothing is impossible, and last year Eugene Potapenko demonstrated it on ITSea event. This is an old story, however, so why this post? Well, because we have some news for you.

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 Shukla, 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 :) Continue reading ‘An update on Livecoding in ActionScript’

Gyroscope adventure

In case you can’t fully understand yet what Adobe means by focusing on (desktop) gaming and video and not general purpose apps, allow me to demonstrate. Suppose you are making mobile app and for whatever reason you want to track device orientation. How hard can that be? Check it out:

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 :)

Free SWF obfuscator update

These days AS3 devs are all moving to AIR, so I am not sure how many of them still feel like they need to protect SWF bytecode. Neverless, my three years old “proof of concept” SWF obfuscator post remains one of the most visited posts of this blog. Guess what – it’s update time! Behold brand new free SWF obfuscator version 2 :) So, what’s new?

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.

Old stuff

May 2018
« Jan    

Oh, btw…