These are exciting times. Today, at the Flash Gaming Summit in San Francisco (of which we’re proud Gold Sponsors), Adobe has announced the public availability of a beta version of the Flash Player, codenamed Molehill, that has a very interesting new feature: hardware accelerated 3D support.

Molehill exposes a very low-level shader-based interface to the graphics hardware. Adobe has decided to focus on that low-level part, and do that really well. The molehill pre-release will not be shipping with a 3D engine, scene building tools, model and animation importers / exporters, physics, lighting or lightmap creation tools, etc.

The article states that Unity will be keeping the Unity Player and the developer will decide when to target Flash or Unity Players or other platforms like desktop, mobile that are currently available and use the rendering platforms that work best with each (DirectX/OpenGL/OpenGL ES/Molehill… maybe WebGL in the future).

There is no announcement of a date but Unity is pretty fast to add updates and new platform versions so if they take this on they will ship. Currently they mention using Unity and coding with AS3 within Unity script or using Mono.NET C#/Javascript/Boo as currently used. An intersting option is using Unity to create content and code in C#/Javascript over AS3.

Unity addresses these issues here:

Q. Is this the end of the Unity’s own Web Player?

Absolutely not. The Flash and Unity Web Players both have their strengths.  We’re excited by the opportunity to target the Flash Player and all of its features with Unity, but there will be plenty of experiences that the Unity plugin is better suited for. It will be up to developers in the end, to decide whether they want to target only the Flash Player, only the Unity Web Player, or some combination of the two (now things are getting interesting!)

Q. What programming language will I use?

You’ll have two options:

1. For people with a Flash background:
   Target our ActionScript API directly from Flash. Think:
   var go:GameObject = new GameObject(“Just normal ActionScript 3 code”);
2. For people with a Unity background:
   Script your content in C# / JavaScript / Boo, like you’re used to, and have Unity automatically translate it to ActionScript when you hit publish.

Adobe is good to move to a model where hardware acceleration is part of the platform.  Since Molehill is low level and competing products like Unity, WebGL, and others would take that in time, opening it so others can build tools on their platform will attract interesting new developments like 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…

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

Mihai Pricope has a post with sources on how he got the ODE (Open Dynamics Engine) a great open source physics engine for 3D, running on the AVM2 Flash Player virtual machine.

I’ve took Alchemy for a test and decided to compile ODE (Open Dynamic Engine). Just to add yet another physics engine to the Flash World. It was a hell of a ride but I finally got to produce some bouncing balls . For a still unknown reason some as 3d libraries have been very slow to render 6 translucent walls and 2 balls. Papervision3D seems to move quite decent.

You can download the ode sources from here. To recompile them do (you need to have the Alchemy environment turned on):

Flash 10 will become mainstream shortly and with that the possibilities of using Alchemy in your projects is becoming a reality for production.  But what specifically can you do with Alchemy, a project that helps to compile C/C++ code into AVM2 capable files?

Alchemy described from Adobe:

With Alchemy, Web application developers can now reuse hundreds of millions of lines of existing open source C and C++ client or server-side code on the Flash Platform.  Alchemy brings the power of high performance C and C++ libraries to Web applications with minimal degradation on AVM2.  The C/C++ code is compiled to ActionScript 3.0 as a SWF or SWC that runs on Adobe Flash Player 10 or Adobe AIR 1.5.

Alchemy is based on the LLVM Low Level Virtual Machine that allows new levels of code translation.  Maybe this can lead to more effective and performing code to run on the iPhone with flash player 10. Or some type of system that allows flash developers to code in AS3 or take projects and get them ready to run on the iPhone much like some of the Java to Cocoa compilation systems and Unity3D using mono to compile down to iPhone capable code.