Less than two weeks left to enter COLT contest

Just to remind you all, free COLT license + a chance to win some Apple hardware are only available until June 25. So download COLT, make your video, upload to youtube, send us the link. Do it now! While you still can :)

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

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

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?

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.

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

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

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.