Apple’s official statement on this topic.

Well good news, after the massive frenzy of 3.3.1 in the App Store Terms of Service, Apple has been wise to loosen restrictions on the AppStore for native apps that use scripting such as Mono, Actionscript, Lua and others as long as it doesn’t download any code (for security reasons). The apps have to be AOT Ahead of Time compiled which Unity, MonoTouch and the AIR iPhone Packager for Flash apps all use or the script has to be downloaded with the binary that was approved or an update (Lua scripting for instance).

This is a huge change in stance for Apple and basically allows Adobe Flash based AIR apps to run on the device natively again. I think this is a very wise decision by Apple to let the market decide on what is a quality app while respecting Apple’s concerns about downloading and running code that might create security concerns (non compiled script outside the web sandbox).

The only bummer is that we won’t see a C++ Unity version which was plan b. But the benefits are really great for all types of developers as long as it is safe and with Apple’s latest update, quality.

Developers using Unity, MonoTouch, Adobe Flash AIR Packager, Lua scripters etc are now all safe as long as it is AOT compiled and scripts it uses are downloaded with the binary and not downloaded later (only content and data can be downloaded unless it is in an approved app update).

All your technologies are safe… for now.. dun dun dun…

However Apple also tightened quality control so they will be rejecting bad or duplicate apps, so at the same time this has made it harder to get apps approved if there is questionable quality or too many of one type of app.  It is good on the surface but also I believe the store should be an open market where the best app wins, crap will naturally filter out.  This is probably a stop-gap for all the apps that will be submitted with AIR or other less complex platforms because more novice users will be submitting them.  So this is good for skilled developers on any platform making quality and original content.  But it could cause some problems.

Engadget has some nice covereage if you dont’ have access to the iOS developer site:

• Apple’s Official Statement regarding this
• Apple backpedaling on some iOS development restrictions, will allow third party tools and ad services
• Apple’s App Store Review Guidelines: ‘we don’t need any more fart apps’
• Daring Fireball on the new changes

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)

Here’s a look at another interesting flash player implementation by Joa Ebert using Java with OpenGL rendering support. It is at an early stage but has the right idea in hardware rendering to OpenGL which is easily cross platform and mobile capable with speed.

This project is pretty new but there is work to make it web browser capable either in a java applet or a plugin for IE/FF/WebKit/etc but there are also others that are out there using alternative renderers. Most of these are in early development with varying support and do not currently compare to Adobe’s Flash Player versions.  However the hardware rendering ones like JITB may beat it fairly quickly once all the other features are added.  Complete OpenGL based renderers like Unity or WebGL are fast and can run pretty heavy rendering because of hardware acceleration for all drawing and native support.

Other Flash Player implementations:

• Lightspark
  • AS3 script via LLVM
  • Written in C++ (very portable for native)
  • OpenGL accelerated rendering
• Smokescreen
  • runs in Javascript/Canvas/html5
  • limited support
• Swfdec
  • Firefox plugin
  • Early development
• Gnash
  • flash 7-9 support

Flash Players that use OpenGL as the renderer are nice because cross platform support is easier.  The reason why OpenGL is a great idea is it is so cross platform on desktop and on mobile, it is also coming soon in WebGL for the browser hopefully.

Versions of OpenGL and support

• OpenGL ES
  • OpenGL ES 1.1 = OpenGL 1.5 and lower (fixed function)
    • Android
    • iOS devices 3rd gen and lessx
  • OpenGL ES 2.0 = OpenGL 2+ (current version 4.1 – shader capable).
    • iPhone (3GS or later), iPod Touch (3rd generation and later) and iPad
    • Android 2.2+
    • WebGL
• OpenGL
  • Windows
  • OSX
  • Linux

There is still a clear open field for an open source player to match something like Moonlight for Silverlight or hardware rendered canvas. WebGL would be great to have in time if it gets support but it is also nice to have a compiled language in the content that works in the player faster than scripting but with the ease of scripting. Plugins are still very relevant if they can address that.

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.

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…

Wow. IE9 just set it in motion.

Canvas 2D is now really on the horizon for all browsers. IE9 preview now supports the <canvas> tag and all canvas element APIs and most Canvas 2D context APIs and attributes!

Features Available

Canvas

• In the latest Platform Preview we support all Canvas element APIs and most Canvas 2D Context APIs and attributes.

Features Partially Implemented

• Canvas
  • globalCompositeOperation
    • The latest Platform Preview does not include support for the globalCompositeOperation attribute.
  • DOM Exceptions
    • The latest Platform Preview does not include support for Canvas 2D Context DOM Exceptions.
  • drawFocusRing()
    • The latest Platform Preview does not include support for the drawFocusRing() Focus management API.

This is pretty amazing even though it has been hinted at by other news (previously from AMD).  Why should we care what Internet Explorer is up to?  Well the dream of standards across web browsers seems to be materializing for html5 and more importantly, canvas 2d.

Even with Silverlight Microsoft has decided to join the party and upgrade the web on some great standards to build even more innovative platforms on top of.  Some may see this as a death knell for Silverlight, Flash etc but I do not see it that way. I see <canvas> as a competing interactive technology but many times technologies bind together for a better experience, they also drive one another to innovate.

Much like Silverlight pushed Flash, and Silverlight was created because of Flash, those two technologies brought on canvas 2D and more graphical capabilities for the web in the interactive, game and application space.  As javascript execution has sped up so has the graphical capabilities of browsers now. What is not to like about that if you are an interactive developer?

Canvas, Flash, Silverlight are all for the most part still software/CPU accelerated. The question is who will start the hardware acceleration of canvas and competing technologies even further to bring us closer to OpenGL ES/WebGL in the browser?

Ars Technica states that IE9 will have hardware accelerated canvas in addition to SVG but that doesn’t seem to be officially stated anywhere by Microsoft yet that I can find.  AMD has hinted at it and previous news about SVG being hardware acclerated.  Time will tell and it will be a HUGE boost to the browsers that do, of course we need all of them to do it to be worthwhile for mainstream content.

Ars on the hardware accelerated canvas support:

What does come as a surprise is canvas support. Microsoft has been promoting Internet Explorer 9′s support of SVG, which provides vector graphics capabilities within the Web browser, but thus far has kept quiet when asked if it would support the canvas bitmap graphics specification. Not only is canvas being supported, it is also being hardware accelerated, continuing Microsoft’s efforts to give Web applications the ability to exploit the extensive hardware capabilities of modern PCs.

Of course we should tread carefully here, there is still a big chance that portions of the canvas 2d spec will not be implemented exactly the same or some browser may have missing features much like CSS and javascript evolution.  For instance the “most Canvas 2D Context APIs and attributes” is something I hope is addressed in the final IE9. If you are gonna spend the time implementing a standard, do it fully and right, don’t try to break it (an old Microsoft tactic). But this step was needed to again push interactive web technologies to more closely compete with desktop graphic technology which adds some really exciting times ahead.

Another golden ray of hope is ES5 support in IE9.  Again Wow!

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);
    }