"flash" Posts

Send us your Tiff files!

Back in April of 2010 we introduced ZaaIL, which was an Alchemy port of the open source C DevIL image library. ZaaIL was released to our labs as simply an experimental project to serve a specific purpose and to also allow for us to learn the ins and outs of Adobe’s Alchemy project.

Since our release of ZaaIL, there have been loads of questions and clients who have contacted us regarding deeper support of three formats: TIFF, JP2000 and DICOM.

We’re happy to announce that ZaaLabs has addressed the first of those three image formats, the TIFF format.

ZaaTiff (AS3 and JavaScript)

We currently have a build of what we’re calling our ZaaTiff library. Below you can see screenshot of us parsing a TIFF file and displaying it in Flash in the browser. We have also built a very rudimentary document viewer using minimal comps.

We also have built out an ExternalInterface JavaScript bridge.

And finally, we have also built out an experimental JavaScript version of the TIFF Parser which renders to an HTML5 Canvas.

We need your help!

The TIFF file specification is expansive, and finding test images of all the different formats is quite difficult. In an effort to make ZaaTiff all-encompassing, we need more test images of varying types.

What we’re looking for:

  • 1 Bit Per Pixel / Group 3 1D / CCITT modified Huffman RLE
  • 1 Bit Per Pixel / Group 3 2D / CCITT Group 3 fax encoding
  • 1 Bit Per Pixel / Group 4 2D / CCITT Group 4 fax encoding
  • 8 Bits Per Pixel / JPEG Compression
  • 8 Bits Per Pixel / LZW Compression
  • 24 Bits Per Pixel / LZW Compression
  • 24 Bits Per Pixel / JPEG Compression
  • Pretty much any TIFF file…

If you have TIFF files sitting around, email them to info [at] zaalabs [dot] com, with the subject of “ZaaTiff Test Image”.

Any questions, comments, etc… feel free to comment below.

Thanks!

Announcing Ninjatude

This morning I would like to announce publicly that we’re currently developing a new cross-platform, cross-device game code named: Ninjatude. Ninjatude is being built on top of the latest Adobe Flash / Adobe AIR platform.

In a place known as The Forest (at least by the locals), there exists a clan of Ninja Squirrels who fight to keep the peace. Filled with the power of their greatest treasure, the mystic Golden Acorn, they root out evil and defend the creatures of the trees. Of course, since no good deeds go unpunished, the Ninja find their great treasure stolen away in the night. Deprived of their strength and ability, the Squirrels have sent out their best lone warrior to retrieve the Acorn.

We’re working with a stellar team of Game Designers, Artists and Developers coming to us from Digipen.

We need your help

I’d like to introduce you to our main character… who has yet to be named. So we need your help. Put your suggestions for names in the comments below. Here is some more concept art to get you thinking.


More information will be coming soon. So be sure to keep checking back here.

Cheers!

Adobe Flex to JavaScript… why Conversion is Hard

I recently had a conversation with Simeon Bateman regarding the woes of mobile web development. We realized one of the reasons why Flex developers as in general have a hard time embracing JavaScript development.

The Problem

The particular JavaScript quirk we were discussing was window.innerHeight functions on mobile devices.  During our development on mobile devices, we ran into two frustrating issues.

Simeon’s issue was with the way window dimensions get messed up when an Android device is re-oriented.

My issue was with the way that window.innerHeight tells you how much space you have with the url bar on the screen, until the url bar is scrolled off the screen, then it reports the actual space that you can work with (since this is my post we’ll talk about my problem). This issue if frustrating because I’m trying to get a webpage to take up the whole screen on the mobile device, with the url bar scrolled out of view.

To illustrate what I’m discussing, I’ll show side by side screenshots.  The screenshot is of a page that reports the screen height and width and the window innerHeight and width and updates them on an interval.  On the left you have the URL bar, on the right the URL bar has been scrolled off the screen.  Notice how the screen size has remained the same, but the window.innerHeight has changed.

Window Size with URL barWindow Inner Height without URL bar

We both understood the problems we faced, but both believed there had to be a good and right way to solve the problem, a “best practice” if you will.  Having spent time working in the Flex community, we had come to expect an elegant way of solving the issues we faced.

Neither of us are foreign to forging our own paths through new territory, but we’re generally used to coming to a solution that feels right.  When things start getting hacky we feel like we’re in the wrong place and try to research the problem looking for a more elegant solution.

Finding A Solution

In our scenario with window.innerHeight we were trying to think how we could go about getting the height of the space we can use in an elegant fashion, and couldn’t come up with anything.  We knew how to accomplish our tasks in an inelegant fashion, but thought it was a common enough task that there would be a “right” or elegant solution.

Finally we realized that we knew of people out there who were doing what we wanted, and this is JavaScript after all, so we went and looked at the source. We checked in a few places, and discovered that most of the places we checked handled this problem in a similar way.  The great guys over at Sencha had this in their code for handling this problem and making sure the application is the correct size.

init: function (c, b) {
    var d = this,
        e = Math.max(window.innerHeight, window.innerWidth) * 2,
        a = Ext.getBody();
    d.updateOrientation();
    this.initialHeight = window.innerHeight;
    this.initialOrientation = this.orientation;
    a.setHeight(e);
    Ext.gesture.Manager.freeze();
    this.scrollToTop();
    setTimeout(function () {
        d.scrollToTop();
        setTimeout(function () {
            d.scrollToTop();
            d.initialHeight = Math.max(d.initialHeight, window.innerHeight);
            if (c) {
                c.apply(b || window)
            }
            d.updateBodySize();
            Ext.gesture.Manager.thaw()
        }, 500)
    }, 500)
}

The variable names are not great as its beautified code that was minified, but if you follow it you can see what they’re doing.

In order to size the app to the proper height and be able to have the url bar scrolled off the top, they have to double the size of the container, to ensure that they can scroll past the url bar. Then they scroll… twice on 500ms timeouts, and then they can fix the size of the app to bring the size down to what it really is without the url bar, since window.innerHeight will now report they value they want.

The Difference

This is where JavaScript development diverges from Adobe Flex development.  The fractured landscape of so many browsers and the impossibility of getting users to upgrade in a timely manner has left JavaScript developers with no choice but to hack their way through.

This is not to say that JavaScript lacks elegance… but that there are some areas where the hack is just what you need to do.

In Flex there are times where you need to implement a hack, but you generally implement it as a patch to the Flex SDK and your application code is spared the hack. This example underscores one of the big issues that Flex developers face as they move from the world of the Flash Player to the fractured world of browsers. To a Flex developer this feels like an inelegant hack, but to a JavaScript developer this is a great solution, because it works across all the different platforms we need to support.

Conclusion

I don’t present this information as a way of excusing Flex Developers from exploring HTML/JS development, but wanted to help developers understand this difference that can help on both platforms.

With this new found understanding if you feel like hopping into some HTML/JS development, may I suggest another article, by Simeon Bateman.

Adobe Flash ExternalInterface issues with Internet Explorer

On a recent project, I was asked to build a simple Flash mp3 player that could be controlled with JavaScript by using ExternalInterface.  I built and tested the whole application in under an hour and was feeling pretty good about myself.  QA filed a bug saying that JavaScript was throwing an error, and it only occurred when my mp3 player was present.

The error only happened in IE8, so I was stuck with IE’s debugger and error messages.  The error was being thrown when the loaded SWF attempted to add callbacks to ExternalInterface using ExternalInterface.addCallback  As soon as this function was called my script threw an error:

Object doesn’t support this property or method

IE 8 Error Screen

The stack trace showed an anonymous JScript block with a function named __flash__addCallback which was throwing the error when trying to append a property to a JScript object. The debugger for this particular error looked like this.

I scoured the internet searching for solutions to this problem as I was sure it had to be something that was well documented.  I came across some solutions that appeared to work for people such as: ensure your object tag has an id, ensuring you set the type or class id on the object tag. These solutions worked for some people, but didn’t solve the problem I was having.

After a little more investigation I realized that some of my ExternalInterface calls were successful, while others were not.  I then realized that play and stop were probably reserved names for IE8 and might be the root of my problem.  I adjusted the names of the callback functions to playSong and stopSong and things started working.

This Doesn’t Work:

ExternalInterface.addCallback("play", play);
ExternalInterface.addCallback("stop", stop);

This Works:

ExternalInterface.addCallback("playSong", play);
ExternalInterface.addCallback("stopSong", stop);

The moral of the story is to avoid common names when using ExternalInterface. Play and Stop I know are reserved, and I’m sure there’s a host of others out there.