Besides recently becoming the most popular configuration in the entire iPod lineup, the iPod Touch “has become the most popular portable game player in the world,” Jobs chimed. “The iPod Touch outsells Nintendo and Sony portable game players combined. It has over 50 percent market share for both the U.S. and worldwide.”

However, as Mike Capps commented to Gamasutra in our interview immediately following the event, “Right now, I can display from my iPad to my Apple TV on a big screen TV. How far away are we from ,’That’s my game console, and it’s displaying wirelessly to my television set?’ It’s not far away.”

…

What will that mean? What form will it take? How soon will it come? All unanswerable. But Sony, Nintendo, and even Microsoft are all officially on notice as of today.

Do consoles anchored to a TV suddenly seem like the old way?

To the argument that the Appstore is full of bad games, it is, but it is also the secret to their success.  Apple built a platform and let indies in.  Apple was very critisized about their approval process but Playstation, XBOX, Nintendo Wii, Nintendo DS, Sony PSP all have more harsh approval processes and dont’ even let indies begin developing until they approve.  The result is higher quality games on the latter devices however it is the same problem the web brought.

I think that was Nintendo and Sony’s downfall in that they didn’t jump on the downloadable store AND allow indies in.  There are lots of fart apps that come with allowing almost everything but you also get stuff like Angry Birds, Monster Dash, Real Racing, 2XL, Gameloft etc.  I’d rather let everything in and let the charts decide what is best rather than it be a closed market to indies from even trying.  But that comes with lower quality games for the most part except those standouts that might have been rejected on Nintendo or Sony platforms. 99% of the Appstore is crap but 1% is awesome, that 1% might be bigger than the quality games that make it to the PSP or DS.

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)

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.

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.

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.

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…

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”

Could it be that Microsoft is innovating again?  IE9 will supposedly be largely hardware accelerated for all graphical elements and possibly <canvas> and <video> html5 tags? IE9 test drive preview available here.

It appears Microsoft has been enjoying the Apple, Adobe, Google smackdowns on each other, got lost in the dust kicked up and just done what many developers want: hardware acceleration. Firefox 3.7 also has hardware acceleration coming down the pike.

Specifically, IE9 will take advantage of the underlying hardware in different ways, both from a visual perspective as well as code execution perspective:

• The MSHTML rendering layer has been enhanced to use Direct2D and DirectWrite instead of GDI.  Direct2D enables GPU accelerated 2D graphics and text, and allows sub-pixel positioning.  In addition, the GPU is used for scaling (bitmaps are mapped to textures), which is ideal for zooming and moving images around the screen.  This GPU support translates directly into improved readability of pages, more precise placement of text and images, and smooth scrolling and zooming.
• JavaScript performance is greatly improved from older versions of Internet Explorer, and should be competitive if not better than competing browsers.  In the past, JavaScript in IE was interpreted and not compiled into native processor instructions.  The JavaScript engine now includes a JIT compiler which emits x86 instructions and compiles the code before it runs, resulting in a dramatic performance uplift.  Instruction generation can also be tailored to the underlying processor to take full advantage of the underlying platform.
• IE9 is more standards compliant than previous versions, with new support for HTML5 elements such as <video>, CSS3 support, and SVG support.  All graphic elements will be accelerated on the GPU and will enable hardware accelerated rendering contexts for application development, improving visual display, reducing CPU usage, and improving power usage.

There is no excuse in this age where most people have at least a 32MB cards even on the lowly intel OEM cards to not take some advantage of hardware rendering/acceleration for aspects of web content including video, 2d, games and even 3d.

There are lots of other areas of browsers and tech that is hardware accelerated such as plugins like Unity (and Director waaay before that), video, and new tools like WebGL/O3D. Firefox 3.7 is also aiming for hardware acceleration.  This idea of browser graphical elements not just in a plugin or video player being hardware accelerated is something that might spark some very interesting and innovative experiences.

I applaud this effort and hope there is truth in it beyond just a preview that has features cut.  I also hope more browsers and plugins start doing the same besides just IE9 and Firefox. This entire blog has pretty much had an underlying hardware rendering/acceleration slant.  I have been pushing this for sometime and I believe the time is coming soon that web developers will be equipped with the power that native and game developers have for graphics soon, mainly for applications, games and experiences.

The best news is that IE9 will support html5 and <canvas>, <video> tags and ensures the new functionality that web developers will be able to use.  We’ll all have to wait for 2-3 years probably before it is something that is 90% saturated and usable in the mainstream market but it is good to know great times lie ahead.

I can’t believe I just wrote about IE possibly innovating ahead of others.

This is pretty huge even for such a small and innovative company. I guess it means it will be time to buy an upgrade soon. Unity so far has been giving feature after feature for free for current license holders, this one seems big enough to justify a major version increase.

Gamasutra comments on other great features:

This third iteration will also incorporate Umbra Software’s occlusion culling product, which is designed help performance for games with large, open scenes and complex geometry. The platform’s top-end version, Unity Pro, will include both Umbra and Beast at no additional cost.

Unity Technologies updated its Unity iPhone for version 3.0 to include streaming audio support for smaller build size, Bluetooth multiplayer support, faster in-game GUIs”, and a 2D sprite engine. Furthermore, the company’s iPhone product will offer performance improvements that promise to provide faster frame rates.

The company says that with its new platform support for PlayStation 3, iPad, and Android, it offers developers an opportunity to target a larger install base than any other game engine. Unity’s game engine currently can produce games for Windows, Mac, iPhone, and Wii, with support for Xbox 360 announced last October.

The sample browser will show you what Balder is capable of and it has come pretty far since the first version showing a wireframe teapot.

You know you’ve made it as a 3D engine when there are Augmented Reality apps for it.

Here’s a glance at what some of the C# source looks like for a feel of the engine code from the Silverlight4 TestApp:

using Balder.Core.Execution;
using Balder.Core.Objects.Geometries;
using System;
using Balder.Core.Lighting;
using Balder.Core;
using Colors=System.Windows.Media.Colors;
 
namespace Balder.Silverlight4.TestApp
{
    public class MyGame : Game
    {
        public override void OnInitialize()
        {
 
            Camera.Position.X = 0;
            Camera.Position.Y = 0;
            Camera.Position.Z = -80;
 
            var light = new OmniLight();
            light.Diffuse = Color.FromSystemColor(Colors.Green);
            light.Ambient = Color.FromSystemColor(Colors.Green);
            light.Specular = Color.FromSystemColor(Colors.White);
            light.Position.X = 0;
            light.Position.Y = 0;
            light.Position.Z = -130;
 
            Scene.AddNode(light);
 
            base.OnInitialize();
        }
 
 
        public override void OnLoadContent()
        {
            var teapot = ContentManager.Load<Mesh>("teapot.ase");
            Scene.AddNode(teapot);
            base.OnLoadContent();
        }
 
 
        private double _sin;
 
        public override void OnUpdate()
        {
 
            Camera.Position.X = (float)(Math.Sin(_sin)*80);
            Camera.Position.Y = 0;
            Camera.Position.Z = (float)(Math.Cos(_sin) * 80);
 
            _sin += 0.05;
            base.OnUpdate();
        }
 
    }
}

• Balder Demo Sample Browser
• Balder at github
• Get Balder Silverlight 3D Engine at Codeplex
• Einar Ingebrigtsen’s Post on Balder Release