Thanks to YouTube for the amazing preview image they picked up for the second video

This release includes a lot of little improvements that we included to either improve your workflow today for mobile development or simply add the things you always wondered why it was not there.

We also added key features like fullscreen text input to enable better gaming experiences for you developers leveraging fullscreen capabilities.

As we mentioned at Max last year, we have in the team an initiative called JDI (Just do it) where the goal is to add those little things which makes your life easier as a developer.

It is generally a very little feature, in the team, we like to say "Tiny APIs, big impact", cause it just makes things easier and better.

Here is below the list of improvements/features added to this release:

• Frame-label events

var frame:FrameLabel = mc.currentLabels[0];

frame.addEventListener(Event.FRAME_LABEL, onFrame);

• Silent auto update for Mac

• Audio latency improvements

• Reduced latency for un-buffered audio playback

• Fullscreen text input

<param name=”allowFullScreenInteractive” value=”true”/>

trace(stage.allowsFullScreenInteractive);

stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;

• Texture streaming for Stage3D

[Embed( source = "MipLevel9.jpg" )]
var MipLevel9:Class;
var context3D:Context3D;
var texture:Texture;

stage.stage3Ds[0].addEventListener(Event.CONTEXT3D_CREATE, createdHandler);

function createdHandler(e:Event)
{
    context3D = stage.stage3Ds[0].context3D;
    //set streaming levels to 9, a 1x1 mip level for a complete texture size of 512 (Mip level 0 =512, Mip level 9 = 1)
    texture = context3D.createTexture(512,512,Context3DTextureFormat.BGRA,false, 9);
    var mip9:Bitmap = new MipLevel9();
    texture.uploadFromBitmapData(mip9.bitmapData,9);
}

• MouseEvent.RELEASE_OUTSIDE

s.addEventListener(MouseEvent.RELEASE_OUTSIDE, onReleaseOutsideHandler);

• ApplicationDomain.getQualifiedDefinitionNames()

var definitions:Vector.<String> = this.loaderInfo.applicationDomain.getQualifiedDefinitionNames();

• BitmapData.drawWithQuality

bitmapData.drawWithQuality(sprite, sprite.transform.matrix, null, null, null, null, StageQuality.BEST);

• Native Bitmap compression : BitmapData.encode()

var bitmapData:BitmapData = new BitmapData(640,480,false,0x00FF00);

var byteArray:ByteArray = new ByteArray();

bitmapData.encode(bitmapData.rect, new JPEGEncoderOptions(), byteArray);

• Background behavior for AIR
• Android 4.0 Stylus Support
• USB Debugging
• Landscape mobile
• Simulator support for iOS

As usual, download everything on Adobe Labs. Let us know if you get any bugs. Thanks!

The BunnyMark demo we showed, uses a tiny framework developed internally at Adobe (named GPUSprite). It makes use of support classes called GPUSprite/GPUSpriteLayer, which optimize rendering by allowing a large number of of sprites to be drawn in a single draw call (batching).

This means all those sprites must be able to sample their image from the same sprite sheet.  Performance is really nice.  You could extend it to multiple sprite sheets, but you will have to organize your content into layers with one layer per SpriteSheet.

All the objects on a higher layer will be rendered on top of objects on lower layers.  For a scrolling game with background, foreground, characters, effect layers and so on, it is a nice authoring solution. Of course this has way more restrictions than what Starling would allow, it actually has very limited features.

So do not consider this as a silver bullet, consider this as an example to learn how to program GPUs efficiently, or also tweak frameworks to achieve higher framerates.

You can download GPUSprite on the GraphicsCorelib github repo.
Download the BunnyMark code (using GPUSprite).

Special thanks to Iain Lobb for the original BunnyMark.
Special thanks to Philippe Elsass for the modified BunnyMark test.

Live demo of GPUSprite below :

You guys may remember the announcement we made at Max last year where Epic announced they were able to target Flash Player now.

You can now see this live by visiting the Unreal website. Make sure you have the RC version of Flash Player 11.2 installed.

In case you are running Chrome, just type about:plugins (in the url) and select the Flash Player 11.2 you installed rather than the embedded one.

We wanted to provide a place to discover what Flash enables for game development, showcase content but also a place to help developers get started with the technology.

And finally, a place to show the world what Flash can do. We hope you guys will like it.

You will be able to develop fully GPU accelerated mobile content with AIR 3.2 for iOS and Android using the same Stage3D APIs you are using today on the desktop.

It allows you to distribute AIR captive runtime versions of apps, enabling you to publish apps immediately to marketplaces such as the iOS App Store, Android Market, and Amazon Appstore. We recommend that you update your applications with the GM build when it is available.

And this is just the beginning of the surprises we have for you, this is going to be an exciting year. The team cannot wait to see what you guys will create, what we have received already from developers on our prerelease looks stunning, as usual I am sure you guys will find very creative ways to use Stage3D for all types of content.

Let us know the content you create by posting a comment here or letting me know through Twitter.
At the same time we are also making available the release candidate of Flash Player 11.2.

Below a video of Lee and I to demonstrate what AIR 3.2 will enable, showcasing some content already produced by the community:

Enjoy!

Description of the book from O'Reilly:

Starling is an ActionScript 3 2D framework developed on top of the Stage3D APIs (available on desktop in Flash Player 11 and Adobe AIR 3). Starling is mainly designed for game development, but could be used for many other use cases. Starling makes it possible to write fast GPU accelerated applications without having to touch the low-level Stage3D APIs.

Most Flash developers want to be able to leverage GPU acceleration (through Stage3D) without the need to write such higher-level frameworks and dig into the low-level Stage3D APIs. Starling is completely designed after the Flash Player APIs and abstracts the complexity of Stage3D (Molehill) and allows easy and intuitive programming for everyone.

Obviously Starling is for ActionScript 3 developers, especially those involved in 2D game development; of course you will need to have a basic understanding of ActionScript 3. By its design (lightweight, flexible and simple), Starling can be used also be used for other use cases like UI programming. That said, everything is designed to be as intuitive as possible, so any Java™ or .Net™ developer will get the hang of it quickly as well.

Here is the table of content of the book:

• What Is Starling? 1
• Why Starling? 1
• Philosophy 1
  • Intuitive 1
  • Lightweight 2
  • Free 2
• How
• Layering Restrictions 7
• Getting Started 8
• Setting Up Your Scene 9
• Wmode Requirements 13
• Stage Quality 14
• Progressive Enhancements 14
• The Display List 15
• Event Model 29
  • Event Propagation 29
• Touch Events 30
  • Simulating Multi-touch 32
• Texture 35
  • Image 37
  • Collision Detection 44
  • Drawing API 46
• Flat Sprites 47
• MovieClip 51
  • Texture Atlas 56
• Juggler 62
• Button 65
• TextField 73
  • Embedded Fonts 76
  • Bitmap Fonts 79
• RenderTexture 88
• Tweens 90
• Asset Management 94
• Handling Screen Resizes 95
• Plugging Starling with Robotlegs 96
• Plugging Starling with Box2D 97
• Profiling Starling 101
• Particles 104

The book is now referenced on the Starling website. Many thanks to Rich Tretola for making this happen with O'Reilly.

To make it short, async workflows allows you to write asynchronous code, as if you would be writing synchronous code, but of course without blocking the UI thread.
Yeah, pretty cool

So generally, when it comes to asynchronous code, you immediately think about event handlers or callbacks. At least for most web developers. It is actually not really a problem today with most web programming languages like JS or AS3, cause there is no real support for concurrency/parallelism (for now). But imagine, if you had to use asynchronous calls in the context of multithreaded code in Java or C#. You could end up with a lot of handlers making your code hard to follow, complex to debug. Also, you will be very likely to share states introduce possible racing across threads. Finally, if you had to handle exceptions on top of all this, you would need to place exception handling almost everywhere.

So, this is why async workflows come to the rescue!

So, let's take a classic example. We have a list and we want to iterate over that list to grab the content of the URL, basically like URLStream would do in AS3:

let urlList = [ "Microsoft.com", "http://www.microsoft.com/"
                "MSDN", "http://msdn.microsoft.com/"
                "Bing", "http://www.bing.com"
              ]

Now let's define our fetch function which will do the job:

let fetch (name, url:string) =
    try
        printfn "Grabbing"
        let uri = new System.Uri(url)
        let webClient = new WebClient()
        let html = webClient.DownloadString(uri)
        printfn "Read %d characters for %s" html.Length name
    with
        | ex -> printfn "%s" (ex.Message)

We are basically grabbing the string from the URL, note that we are using here the synchronous API DownloadString.

Now, lets, iterate over our list and call the fetch function:

let runAll() =
    urlList
    |> List.map fetch
    |> ignore

If you remember the last post about F#, we use here the forward pipe operator that allows us to pass the result of a function to another in a very natural way. We simply map the fetch function on each element of our list

Ok, now, let's execute everything :

open System.Net
open Microsoft.FSharp.Control.WebExtensions

let urlList = [ "Microsoft.com", "http://www.microsoft.com/"
                "MSDN", "http://msdn.microsoft.com/"
                "Bing", "http://www.bing.com"
              ]

let fetch (name, url:string) =
    try
        printfn "Grabbing"
        let uri = new System.Uri(url)
        let webClient = new WebClient()
        let html = webClient.DownloadString(uri)
        printfn "Read %d characters for %s" html.Length name
    with
        | ex -> printfn "%s" (ex.Message)

let runAll() =
    urlList
    |> List.map fetch
    |> ignore

printfn "Starting"
runAll()
printfn "Done"

And here is the result :

Starting
Grabbing
Read 1020 characters for Microsoft.com
Grabbing
Read 35705 characters for MSDN
Grabbing
Read 30677 characters for Bing
Done

Ok, synchronous behavior, pretty simple, but actually pretty cool. Would be useful to have more synchronous APIs in Flash

Now, let's imagine we would like to make this asynchronous so that it does not block my UI, we would generally need to use an async API which would require the use of an event handler/callback. I actually don't want to do that, cause it would force me to change the structure of my code inside my fetch function, I want my syntax to remain linear and not have to jump somewhere else.

Good news, async workflows solve that:

let fetchAsync (name, url:string) =
    async {
        try
            printfn "Grabbing"
            let uri = new System.Uri(url)
            let webClient = new WebClient()
            let! html = webClient.AsyncDownloadString(uri)
            printfn "Read %d characters for %s" html.Length name
        with
            | ex -> printfn "%s" (ex.Message)
    }

Did you see the bang (!) character we used after the let for the html content? We call this the "bang" operator.

The effect of let! is to enable execution to continue on other computations or threads as the async operation is being performed. After the asynchronous call terminates, the rest of the asynchronous block code (asynchronous workflow) resumes its execution. Behind the scenes, when executed, the async block will create a new thread from the pool, execute the asynchronous operation and then the thread is released.

OK, so now let's apply this!

open System.Net
open Microsoft.FSharp.Control.WebExtensions

let urlList = [ "Microsoft.com", "http://www.microsoft.com/"
                "MSDN", "http://msdn.microsoft.com/"
                "Bing", "http://www.bing.com"
              ]

let fetchAsync (name, url:string) =
    async {
        try
            printfn "Grabbing"
            let uri = new System.Uri(url)
            let webClient = new WebClient()
            let! html = webClient.AsyncDownloadString(uri)
            printfn "Read %d characters for %s" html.Length name
        with
            | ex -> printfn "%s" (ex.Message)
    } |> Async.Start

let runAll() =
    urlList
    |> List.map fetchAsync
    |> ignore

printfn "Starting"
runAll()
printfn "Done"

Notice that we execute the async computation with the Async.Start call inside the fetchAsync function.

And here is the result:

Starting
Done
Grabbing
Grabbing
Grabbing
Read 1020 characters for Microsoft.com
Read 30677 characters for Bing
Read 35705 characters for MSDN

Sweet! Our code is now asynchronous, parallelized, and we retrieved the result of the asynchronous call in a synchronous fashion!

Simple, clean, efficient and safe

I hope you liked this intro to async workflows. Learn more about it here.

Note that you guys now have access to standalone debugger builds. Yeah, I know. After 4 years, it was about time! The cool news is that those builds introduce a few cool new features, like mouse lock, right and middle click events and the ability to disable the context menu entirely.

Mouse lock:

A new mouseLock property has been added to Stage. To enable mouse locking set Stage.mouseLock to true. There are several rules which are applied here:

• This property can only be set in full screen mode.
• It dispatches a runtime exception if it is called in non-full screen mode.
• On mobile settings this property always throws an exception. The reason is simple: This feature can only work with a mouse typeof devices and mobile devices do not have such a thing.
• The property can be read in non-full screen mode. This allows developers to easily dispatch to alternative input methods if mouse locking is disabled externally for some reason.
• When exiting full screen mode Stage.mouseLock is automatically set to false. Note that while in full screen mode mouse event listeners attached to other display objects but the stage will not be dispatched.
• In other words to receive mouse deltas and any other mouse event while mouseLock is active you need to attach your mouse event listeners to the stage.

Relative mouse coordinates - New properties (movementX and movementY) on MouseEvent:

When Stage.mouseLock == true:

• MouseEvent.localX and MouseEvent.localY will contain 0.MouseEvent.movementX and MouseEvent.movementY will contain delta values.
• MouseEvent.movementX and MouseEvent.movementY are never transformed based on stage transformation, i.e. they always remain in screen space.
• MouseEvent.movementX and MouseEvent.movementY will be 0 when Stage.mouseLock == false.

Situations where mouse locking is disabled automatically and the mouse cursor is made visible again:

• When the user hits ESC.
• When the window loses focus, for instance when the user hit CTRL-TAB.
• When any settings UI is visible (that includes all privacy dialogs). When a native dialog is shown, for instance a file upload dialog.

Right and middle click events:

Just like with Adobe AIR, right and middle click events can now be used to inside Flash Player. When a listener is registered to the MouseEvent.RIGHT_CLICK event, the native context menu will not show up, allowing you tocreate your own context menu.

I am sure you guys will make good use of that!