Archive for the 'news' Category

Apparat 1.0 RC7 Is Here

I wanted to make a simple bug fix release for Apparat since I solved some bugs and issues. However there are two additional features that are worth mentioning. First of all Apparat comes now with an ASMifier tool. This allows you to let Apparat generate code from an existing SWF. It will create a file that contains a basic class structure with statements that you can directly use for __asm optimizations. You can also suppress all log output and turn Apparat into quiet mode by specifying -Dapparat.quiet=true.

Also worth mentioning: JITB ships now by default with Apparat. What does it mean? Quadruple-rainbow in your face. You can now run your SWF files with JITB if you follow the five golden steps to pure happiness:

  1. Download and install Scala 2.8.0
  2. Type scala in a terminal, then type println(System getProperty "java.library.path" split java.io.File.pathSeparatorChar mkString "\n") and remember one of the folders
  3. Download LWJGL 2.5 and extract somewhere
  4. Copy the native libraries which are located in lwjgl-2.5/native/YOUR OS/ into one of the folders that the Scala command showed you
  5. Open a terminal, go into the Apparat installation directory and type ./jitb some.swf to launch JITB

Now here is the problem. JITB is not complete and so it will probably fail with your SWF — In fact I can nearly gaurantee you that it will not launch your SWF. I included JITB basically because it already allows you to use GLSL shaders very easy and I know a lot of people would like to play around with that.

However I have created an archive of all files I showed at FOTB besides the files that came from David’s laptop since I do not have them on my machine. You might be interested in checking out Example12.as which is the one that uses GLSL shaders. If you want to compile your own version you will need to link apparat-ersatz.swc as an external library since it contains the ContinuousFileLoader and GLSLShader class. Happy hacking!

Update: Also read Ray tracing with Pixel Bender using JITB by David Laenarts for details on the FOTB demos.

Disappointment No. 3

I created a couple of programs like AS3doc and AS3V. Both have never really gotten any adoption because I canceled their development. The reason was that Adobe shortly before or after I finished my tool released a competitive tool. Given the fact that I work fulltime on audiotool.com it is hard for me to find some time off to develop those applications. Some of them are even not written for myself — like the FlexMojos code coverage.

However it happened again. I write a tool that is not even fully released yet and there comes Adobe around the corner with something that must have been in development for a while. Enough time to tell us that we can decide if we want to continue working on it or not.

I have no problem with Adobe developing such products. In fact I second that they have a Flex QA team which develops tools like FlexPMD and the recent coverage plug-in. However the way this process happens really frustrates me. Why would I want to work on something that Adobe is already developing somewhere silently and release it without giving anyone notice? But they do not owe me an explanation for what they do. It would also be arrogant to say that I demand to know upfront.

I am just sad that there is no dialog at all. This happened three times now. I will not continue doing this.

That does not mean I will stop working on Apparat and JITB. Only no more enterprise releated open source software.

PixelBender Support In Apparat

Since PixelBender is becomming a more popular technology in the Flash ecosystem I decided to add first-class Apparat support for it.

As you might know I have done a couple of different tools for PixelBender already.

When I switched to Linux a while ago I had to discover that there is no compiler for PixelBender available and also no PixelBender toolkit. Even PBDT does not work on Linux since it requires a compiler.

In the current state Apparat can read and write PBJ files. I already implemented the format two years ago for the outline view plug-in. But this time Nicolas Cannasse’s great work on the hxformat library was my reference.

I will add two optimizations specific for PBJ files. TAAS will not be used here since it is only an unnecessary overhead. You do not have to crack a nut with a sledgehammer. The PBJ format is already register based and has certain useful invariants.

To cleanup some mistakes of the PixelBender compiler I will add:

  • Copy propagation
  • Dead Code Elimination

The compiler is not bad. Compared to the ASC it is a beauty of technology that makes use of the LLVM. However I think there must be some mistake in the code since unnecessary registers are used (Note: I doubt this is LLVMs fault but more the way how methods like sampleNearest are bound by Adobe). This can be solved with the simple optimizations I will add.

I will add some more things as well like a GLSL conversion or a DSL to write PixelBender kernels in Scala. If we get lucky this will also lead to a true cross platform opensource compiler for the PixelBender language. I think I will name that compiler Hydra :P

New Apparat Example

Good news everyone. The Apparat inline expansion works now to full extent after fixing some minor bugs. A complete example is also available. Just change the paths in the build.properties file and compile everything using Ant.

Apparat Example

Use the inline feature with care. Apparat does not try to optimize your code and performs nothing but dead simple inlining. This can lead to slower code due to the creation of lots of local registers. Your code gets also much bigger and will require more space in memory. I am actually not a fan of manual inlining at all. I think it makes only sense to inline code if you have a powerful optimizer available that will cleanup the whole mess.

The fun story about this example is that the inlined version is slower using the lastes Flash Player release candidate if you have only 40.000 particles. That is why I increased the number of particles to 80.000 ;). I developed the example using an old standalone player and the inlined version was nearly twice as fast. However when I watched the example in the browser with the latest release candidate the game was completely different. Kudos to Adobe for significantly improving the Flash Player performance!

Inline Expansion

In addition to macro expansion Apparat has now inline expansion as well. It works nearly the same way as macro expansion but without most of its limitations. To define a class for inline usage it must extend apparat.inline.Inlined and all its methods must be static. However the cool thing is that you can also return values in contrast to macro expansion. You can also pass normal parameters. For instance FastMath.sin(FastMath.sqrt(2.0)) is valid code using inline expansion. It is enabled by default in TDSI.

Macro Expansion

Apparat has another new feature called Macro Expansion. I talked about this with Nico Zimmermann at FFK in Cologne. Nico was using TDSI for a project but he was not very satisfied with it because you have to inline all inverse-square root tricks manually.
This is why Apparat has now macro expansion. I am actually not a big fan of it. I think a good compiler would do this for you without you having to go through all the steps. Unfortunately writing this compiler will take longer than the couple of hours I have spent on the macro expansion today.

So if you want to have quick and dirty inlining capabilities: this is for you. It is an easy fix for a feature a lot of people have asked for. I will continue working on TAAS to implement this much better in the future.

Apparat: Crunching SWF Files Since 2009

Apparat has a great new feature that allows you to create even smaller files. Basic SWF files are compressed using Java’s standard java.util.zip.Deflater class. This is perfectly fine. And I would even go with no compression at all during development.

However when deploying you can spend some extra time compressing your SWF files with the best tools available. 7-Zip is for instance such a tool and achieves a great compression ratio.

If you have the 7z executable on your PATH Apparat will make use of it to achieve the best compression for your SWF files. More configuration options are available here.

This feature is currently only implemented for SWF files and not SWCs. However every tool will make use of it by default. So if you are running Reducer and have no graphics in your SWF files you can still get a better compression.

An example is straight from the sources:

reducer -i as3\Apparat.Tests.AS3\bin\Test07.swf
[i] Apparat -- http://apparat.googlecode.com/
[i] Launching tool: Reducer
[i] Waiting for 7z ...
[i] Compression ratio: 18.224573%
[i] Total bytes: 310
[i] Completed in 547ms.

Note please that this SWF file does not contain any graphical assets and we got still a ratio of 18%. Our main audiotool.swf file is compressed by about 10% — about 200kb — and contains no graphical assets either.

You can download the latest Apparat on Google Code. Please note that you will need Scala 2.8 RC1 as well.

Audiotool 1.0

We have finally released the first version of the Audiotool. I am very thankful for all the kind tweets and happy that our work is now available to the public.

However the current version is named Firestarter for a reason. What you see online is just the tip of the iceberg. I can not wait to start implementing all the cool features that will separate us from traditional software ;)

TAAS As A Decompiler

The TAAS compiler is different from the ActionScript compiler since its input is not ActionScript source code but already compiled SWF or SWC files. Just like the haXe compiler can output AS3 instead of a SWF the TAAS compiler can do the same.

Now if you add one and one together you see that the TAAS compiler can be used as a very strong decompiler. My own tests have shown that it will work flawlessly where other commercial decompilers output rubbish. Since the compiler behaves like the Flash Player it will “execute” the bytecode in order to parse it which means it has a very highlevel understanding of the structure inside the SWF.

The only question is now what to do with the source code. I wrote the decompiler for my session at FOTB to show much easier how the optimizations behave. It is also a great tool to debug errors. But should it be opened or not?

To take it one step further one might also be able to write an obfuscator using the TAAS compiler. In my opinion it would be cool to have a strong decompiler and obfuscator, both being open source. We might also add an option to protect SWFs from the decompiler by adding something to the SWF metadata for instance. Of course this is just a simple rule which could be removed by someone once the code is open. What do you think?

FOTB Recordings

The people from Powerflasher were kind enough to upload their recording of my FOTB session. I am sorry that the microphone stopped working at the end. But you might still be able to understand what I was talking about if you turn up the volume of your speakers.
Continue reading ‘FOTB Recordings’