It’s about time. Here at drawlogic we have been pushing hardware acceleration in Flash as it died in Adobe’s Director product that is all but history. Director was horribly not useful as a programming tool but Flash and AS3 have become a great environment, the only thing missing was getting past software rendering limitations to use hardware acceleration that have been made more apparent by mobile devices which are like late 90′s early 00′s computers.

With Flash gaming being so huge and competitors like Unity it is surprising it took this long but it seems Flash and AIR development will be kicking up a notch in 2011 with hardware acceleration.

Adobe has finally delivered or will so in 2011 on this pressing need.

It’s a good thing ByteArray (Thibault Imbert – the man inside) got in there at Adobe he has been there delivering killer stuff and presents a video on Molehill on Adobe Labs showing this new tech.

“Molehill” is the code name for a new set of low-level, GPU-accelerated 3D APIs that will enable advanced 3D experiences across screens through the Adobe® Flash® Platform runtimes. These new low-level APIs will provide advanced 3D and 3D engine developers the flexibility to leverage GPU hardware acceleration for significant performance gains. Today, Adobe Flash Player 10.1, renders thousands of non z-buffered triangles at approximately 30 Hz. With the new 3D APIs, developers can expect hundreds of thousands of z-buffered triangles to be rendered at HD resolution in full screen at around 60 Hz. Using the new 3D APIs in Flash Player and AIR will make it possible to deliver sophisticated 3D experiences across almost every computer and device connected to the Internet.

Developers will be able to create content through the upcoming Flash Player beta program starting in the first half of 2011. To leverage the 3D features exposed in Flash Player during the beta period, developers will use Adobe Flash Builder™ or the Adobe Flex® SDK with an updated SWC exposing the required APIs.

More on the capabilities and rendering tech:

Developers were told to expect “hundreds of thousands of z-buffered triangles to be rendered at HD resolution in full screen at around 60 Hz” under the new APIs, compared to “thousands” of un-z-buffered, 30Hz triangles under the current Flash Player 10.1.

The acceleration will rely on DirectX 9 standards on Windows, OpenGL ES 1.3 on Macs and OpenGL ES 2.0 on mobile platforms, and potentially puts Flash more directly into competition with 3D-centric web game engines such as Unity.

We are very excited about this development and what it means to Unity, WebGL and other technologies that have filled the gap. With Adobe making this change and recent tool support for html5 it seems the old Macromedia innovative spirit has been awoken. I only wish it could have kicked into high gear in 2007-2008 when mobile made native and hardware acceleration necessary again and probably for good.

As we learn more and get our hands on it we will be posting much more on ‘Molehill’.

Unity 3 has been released.  It was released to the world late yesterday.  I have been using it for a few beta releases and it is very nice and many great improvements.  One awesome improvement is the occlusion culling was ported from iPhone to all Unity builds. Other notable features are a unified editor for all platforms, deferrered rendering and more.

Grab Unity 3 and take a spin.

Occlusion Culling Demo

Unity 3 Feature – Occlusion Culling with Umbra from Unity3D on Vimeo.

Chromium is moving to GPU hardware accelerate rendering all types of web content as much as possibly with their latest efforts.

For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS transforms are a major motivation for this work, but it also lets Chromium begin to take advantage of the GPU to speed up its entire drawing model, including many common 2D operations such as compositing and image scaling. As a lot of that work has been landing in tip-of-tree Chromium lately, we figured it was time for a primer.

The primer they are looking at is not just rendering the content made in WebGL, CSS3 3d transformations and more but the entire final pass of the output.  This leads to some very interesting years ahead in browsers.  With Chromium, IE9, Firefox and Safari all now with aspects of hardware rendering and acceleration via the GPU, anyone not doing GPU acceleration is seemingly behind the curve that seemed to start in 2007ish to a culmination of today’s latest browsers.

After these layers are rendered, there’s still a crucial last step to blend them all onto a single page as quickly as possible. Performing this last step on the CPU would have erased most of the performance gains achieved by accelerating individual layers, so Chromium now composites layers on the GPU when run with the –enable-accelerated-compositing flag.

Web content will get really interesting over the next couple years.  Even basic computers now have a GPU and bottom of 32MB video memory.  Why aren’t we using those GPUs as much as possible for web content and web games. The time of software rendering might be coming to an end now that processors seem to have topped out and the bottom level computer is capable of handling a decent amount of video memory. It will be easier to justify useful graphics acceleration with a better user experience when we can take advantage of all the computer/device has to offer.

• Chromium Blog post about this development
• Differences between Chrome and Chromium (the project behind Chrome)

Pretty sweet web racing advergame for Disney’s The Sorcerer’s Apprentice by C4RL05, made with Unity. Carlos Ulloa is of course the same dude that made the Unity HelloRacer. He is also famous for starting Papervision3D for Flash but has been doing some amazing work in Unity for more immersive 3D experiences.

The game is another example of how when you need really immersive experiences for advergames or brands, Unity is looking like a great choice. Unity isn’t perfect for many things that Flash is such as video, 2d games, mixing media, mic/cam apps, and data, but for games where 3d is required it seems to be the way to go.

On the web based gaming front…

Google looks to be making a gaming site to compete with Facebook only kicking the gaming up a notch? By the comment from Mark DeLoura, head of developer advocate for Google gaming, it appears they/he also favor going 3d or native client with WebGL or Unity wrapped in the native client.

Check the comment by Mark DeLoura on the gamasutra post regarding the rumored Google Me Facebook like gaming/social site:

I think Flash will continue to be a very viable platform. The Flash toolset is pretty frickin’ amazing, and there are a ton of happy Flash developers out there, and great games galore.

I would like to see higher-fidelity 3D content on the web though. It’s been a dream of many people going back to VRML days. WebGL and Native Client are two solutions to this that will be integrated into the Chrome browser. At Google I/O we talked about Unity running inside of Native Client, which combines the hardware acceleration and security of Native Client with the fantastic toolset and runtime from Unity. It’s peanut butter and chocolate (well, for me). This is a platform I’m really excited about for 3D web games.

Indeed peanut butter and chocolate is mighty tasty.

Alessandro Pignotti’s project looks to be the start of something good to come. Lightspark Open Source Flash Player [github]has some really nice features that should influence the Flash Player and maybe even draw some interest from Adobe?  Maybe it can be like the Moonlight player for Silverlight only broader.

One such awesome feature is OpenGL GLSL hardware rendered shaders for elements of flash. Flash has Pixel Bender which is pretty nice but having GLSL shaders and the use of OpenGL directly is great.

Features

• JIT compilation of ActionScript to native x86 bytecode using LLVM
• Hardware accelerated rendering using OpenGL Shaders (GLSL)
• Very good and robust support for current-generation ActionScript 3
• A new, clean, codebase exploiting multithreading and optimized for modern hardware. Designed from scratch after the official Flash documentation was released.

A sweet engine for getting started with Android game development is the andengine 2D OpenGL ES engine. This is very simple and compares with cocos2d-iphone for iOS development in 2D with OpenGL ES.  They both support a wide range of 2d techniques with an OpenGL renderer.  Some great videos are posted on the andengine google code page showing a box2D example, multiplayer example and more.

Mobile games are on slower hardware, similar to later 90′s computers so native is a great way to go for 3d and 2d game development because of this limitation at the current time and well into the next few years.  Take this time to learn you some native gamedev. andengine isn’t native directly as it is Java based but compiled with the Dalvik JIT virtual machine. Another way to go native on Android is the Android NDK which allows C and C++.

• andengine download at google code
• andengine examples at google code
• andengine blog
• Mercurial repository at google code
• cocos2d-android port of cocos2d-iphone with BSD license
• rokon android is another BSD licensed android game engine

The engine also has extensions that can be easily added and some great ones exist already.

• AndEngine Live-Wallpaper Extension
• AndEngine .MOD-Player Extension
• AndEngine Multiplayer Extension
• AndEngine MultiTouch Extension
• AndEngine Physics Box2D Extension
• AndEngine Augmented-Reality Extension

Unity is a great and agile company that responded to the iOS4 changes with something very nice, a C++ option to develop with the Unity engine on the iOS. They will implement this if using Mono is barred which so far hasn’t happened.  I have to say I wish this was an option for the Unity Engine all the time and hope they implement it anyways. For now Joachim Ante on the the Unity blog says this:

We continue to be excited about the iPhone, iPod touch and iPod as platform targets for Unity developers. While we don’t think C++ is the best language to write game code , using C++ as a scripting language has memory and performance advantages on low-end devices. This is a great feature to have for developers who want to squeeze the last ounce of memory & performance out of their games.

We still can’t believe Apple will force developers into choosing a specific language for development. And as mentioned, Apple is still approving every Unity-based game we know of. In case the situation changes, rest assured that we are working this Plan B.

We’ll be ready to talk more about this as well as share some time-line information with you soon, while of course waiting to find out if any of this will actually be necessary.

The Unity Plan B is that the C++ engine code that mimics as closely as it can to the Mono .net C# or Javascript code. From the samples on the blog the C++ and Mono (javascript in this case) samples are really similar.

Many current engines are legacy or have lots of bloat, unless you write your own, or maybe even still then. Though this is looking really clean for C++ game engine code, at least in comparison to current industry leaders for indie engines.

It would be a beautiful C++ library to use even if Apple doesn’t require it. Compared to the other indie game engines out this would be a sweet C++ engine for indies and hope they do this no matter. C++ can be written cleanly and with influence from a simplified C#/Javascript engine and clean API it makes for a killer C++ engine that makes sense. Right now native is really attrctive on embedded for some years to come.

A very basic comparison from their blog:

Javascript Sample

function Update(){
    //Spin the object around the world origin
    transform.RotateAround(Vector3.zero, Vector3.up, 20 * Time.deltaTime);
}

C# Sample

using System.Collections;
using UnityEngine;
public class Example  : MonoBehaviour {
    void Update(){
        //Spin the object around the world origin
        transform.RotateAround(Vector3.zero, Vector3.up, 20 * Time.deltaTime);
    }
}

C++ Sample

#include "UnityEngine.h"
class Example : public MonoBehaviour {
public:
    void Update() {
        transform.RotateAround(Vector::zero, Vector3::up, 20 * Time::GetDeltaTime());
    }
};

Things I am wondering…

• Will this help porting to Android versions if they use the NDK?
• How much smaller will my app be if I use the C++ version (attractive feature since the mono dlls are pretty big – even though I really dig mono)?
• Wouldn’t a C++ version be a better base with pluggable scripting in C# if you want? Maybe an option for Lua with a similar API signature for all? Ok maybe over-engineering there…

Google has decided to put weight behind WebGL and stop actively developing O3D as a plugin, rather they will make O3D a Javascript library on top of WebGL. This will focus the 3D plugin development efforts from Google into just WebGL on top of the OpenGL ES 2 spec, which in turn runs in the html5 <canvas> tag.

WebGL is pretty exciting offering browser based OpenGL and hardware rendered graphics. When this becomes mainstream this will change up gaming and interactive on the web immensely. Unity 3D and Flash 3d engines add lots of immersive environments and WebGL will be just as exciting, if all browsers adopt it (canvas/webgl).

At Google, we’re deeply committed to implementing and advancing standards, so as of today, the O3D project is changing direction, evolving from its current plug-in implementation into a JavaScript library that runs on top of WebGL. Users and developers will still be able to download the O3D plug-in and source code for at least one year, but other than a maintenance release, we plan to stop developing O3D as a plug-in and focus on improving WebGL and O3D as a JavaScript library.

About WebGL

WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as Document Object Model interfaces. Developers familiar with OpenGL ES 2.0 will recognize WebGL as a Shader-based API using GLSL, with constructs that are semantically similar to those of the underlying OpenGL ES 2.0 API. It stays very close to the OpenGL ES 2.0 specification, with some concessions made for what developers expect out of memory-managed languages such as JavaScript.

WebGL brings plugin-free 3D to the web, implemented right into the browser. Major browser vendors Apple (Safari), Google (Chrome), Mozilla (Firefox), and Opera (Opera) are members of the WebGL Working Group. “It feels like, someone’s missin-ing”

A new Javascript 3D Engine that can render to Canvas and SVG has been released by mr. doob.

Mr. doob is a well known Flash developer that has added many great experiments and cool contributions without being stuck to one technology, making some great interactive projects in javascript, chrome experiments and html5 (canvas/svg) in addition to the work in Flash with toolkits like Papervision 3D.  Recently the Harmony html5/javascript sketching project generated lots of interest for an html5 sketching app.

Three.js is great because it is a 3d engine built with renderers in SVG and Canvas makes to a really good base for modular, cross platform 3d engine right now (as soon as IE9 joins the party). For a while a good javascript rendering library will need to support multiple renderers for browser differences in performance and supported dependencies like canvas, svg and webgl. Three.js has that reality as part of the design.

Currently the engine only supports particles and triangles/quads with flat colors. The aim is to keep the code as simple and modular as possible.

At the moment the engine can render using <canvas> and <svg>. WebGL rendering would come at a later stage but feel free to fork the project and have a go.

Although this allows 3D for iPhoneOS and Android platforms the performance on these devices is not too good.

• Blog post on the Three.js project
• Three.js at github
• Demos
  • Cube
  • Random
  • Waves
  • Floor

Sample Code:

var camera, scene, renderer;
 
    init();
    setInterval(loop, 1000 / 60);
 
    function init()
    {
        camera = new Camera(0, 0, 1000);
 
        scene = new Scene();
 
        renderer = new CanvasRenderer();
        renderer.setSize(window.innerWidth, window.innerHeight);
 
        for (var i = 0; i < 1000; i++)
        {
            var particle = new Particle( new ColorMaterial(Math.random() * 0x808008 + 0x808080, 1) );
            particle.size = Math.random() * 10 + 5;
            particle.position.x = Math.random() * 2000 - 1000;
            particle.position.y = Math.random() * 2000 - 1000;
            particle.position.z = Math.random() * 2000 - 1000;
            particle.updateMatrix();
            scene.add( particle );
        }
 
        document.body.appendChild(renderer.viewport);
    }
 
    function loop()
    {
        renderer.render(scene, camera);
    }