This is a very cool project called V8-GL.  It is an OpenGL engine with 80% of the API converted to run on the V8 Javascript engine, the same engine that runs Google Chrome.

This is exciting as more productive languages like Javascript get speed boosts from engines like V8 and are capable of manipulating more complex systems like OpenGL.  Google is also pursing this in the browser with O3D with javascript manipulation of hardware rendering.  Also, a Google funded project called Unladen Swallow is converting Python to the LLVM virtual machine, so that it can have increasing speeds to compete with gcc speeds.

Making things easier to produce and control with more simplified and minimal languages like Javascript, Python and Actionscript etc that control more complex systems, that typically you would need to invest more time in such as a platform on C++ is the goal. V8-GL has this goal in mind.

V8-GL from the author states:

V8-GL intends to provide a high-level JavaScript API for creating 2D/3D hardware accelerated desktop graphics.

In other words, you can hack some JavaScript code that opens a desktop window and renders some 3D hardware accelerated graphics. Bindings are made using the V8 JavaScript engine.

• V8-GL blog post
• V8-GL source on Github
• Also check out the SpiderMonkey jslibs project with other javascript wrappers for libraries like ode, sdl and more using the engine by Mozilla.

haXe is an interesting programming language that allows abstracting the source from platform target.  It outputs for targets such as Actionscript and Javascript from haxe language source. But, haXe can also output to native code to run on Windows, Mac OSX, and Linux.

Well because of this it is possible to run haXe on the iPhone. The gamehaXe site has found a way to get haXe to compile to iPhone via hxcpp which creates a C++ output from haXe code very similar to Actionscript 3.

I am a bit late to the party but this is great news. It uses the NME library which will allows code to mostly be written to the Flash 9 API and create the C++ for XCode to compile and run on the iPhone and Touch. This creates a path to port Flash games to iPhone/Touch.

This project is one to watch and participate in.  Native compilation to the iPhone from haXe is a more simplified code to write in while providing lower level performance which is needed on mobile devices, as processors, cache and ram are much lower than desktop and below what is capable of running the Flash AVM2 currently.

If you have more interest in haXe there are some other great demos on as3/haXe at the game haXe site. Also, Tony at touchmypixel.com has posted some very useful information to help you get started with hxcpp.

The hxcpp project is a newer output target along with a java one but this could be interesting if actionscript like code and many libraries like Physaxe or AS3 libraries could be ported to haXe to output to the iPhone.

Flash 10 will be ready for mainstream hopefully by the end of this year, or early ‘10 when the penetration numbers will be up in or around the 90% range via zeh fernando based on previous trajectories.  

With that, Flash 10 has many great new things such as the Vector structure that allows a collection of a certain type, which results in a faster collection because of the known type.  So anywhere where Arrays are used, that is a possible candidate for a performance increase within some code because you are asking the virtual machine to do less work on each loop (not having to dynamically find out the type).

ByteArray (Thibault Imbert) has demonstrated that for the JPEG encoding in corelib it is up to 2.5 times faster using Vectors than Arrays.  Your mileage may vary heavily but it is almost a guaranteed speed boost due to less work.  This obviously has great possibilities for speeding up code that uses lots of arrays.  

Due to the performance boost the Vector does have some constraints in the typical give and take of coder flexibility with compiler and virtual machine overhead.  Vectors are more explicit and strongly typed which is why they are fast, but this is also limiting.

In addition to the data type restriction, the Vector class has other restrictions that distinguish it from the Array class:

• A Vector is a dense array. Unlike an Array, which may have values in indices 0 and 7 even if there are no values in positions 1 through 6, a Vector must have a value (or null) in each index.
• A Vector can optionally be fixed-length, meaning the number of elements it contains can’t change.
• Access to a Vector’s elements is bounds-checked. You can never read a value from an index greater than the final element (length - 1). You can never set a value with an index more than one beyond the current final index (in other words, you can only set a value at an existing index or at index [length]).

 [ Vector docs  ]

ByteArray not only used Vectors heavily but did other optimizations that are always good to do, even though optimization is evil when you are working with precious client side resources ensuring an optimized base starting point can be a good thing.

So what did I do ?

• I used bitwise operators as much as possible.
• I replaced all Arrays with fixed length Vectors.
• I used pre-incrementation rather than post-incrementation (thanks Joa for this one ).
• I casted to int all my Vector indices access.
• Other minor stuff you always do to optimize your code 

Other sources as well for even more optimization or shall I say efficient AS3:

• Polygonal Labs Using Object Pools
• Joa Ebert Tweening and Object Pools
• Joa Ebert Optmization Wiki
• Sean Moore Efficient AS3 roundup (great list of resources for more at the bottom)
• Lost in Actionscript Efficient AS3 Tips
• Big SpaceShip Mouse Leave Tip (flash can hog resources so when it isn’t in focus then let is stop tasking the processor)
• Grant Skinner Idle CPU in AIR FPS Tip (set fps to a lower amount when it is out of focus)

Unity 3D iPhone was updated recently to 1.0.2 and it has been greatly improved in performance and a much more solid 1.0 toolkit.  According to Unity 3D information by up to 50% which means much more room for assets to munch memory for us yay!

I updated to iPhone SDK 3 beta 4 and iPhone OS 3 beta 4 and the latest Unity iPhone and things were much better in perception of speed at least in early testing.  Not sure if it was more from one or the other but the games I am testing/building so far are quicker and the OS feels faster overall.

Get the latest Unity 3d iPhone dev kit (only for Mac OSX obviously since it uses XCode to compile per Apple licensing requirements)

This build fixes many issues and makes some great optimizations for speed as listed here:

New Features and Improvements

• Reduced memory footprint for uncompressed audio by 50%
• “Memory usage for textures reduced by 50%. Texture memory is now freed once it has been submitted to OpenGLES on the device. The “Enable Get/SetPixels” flag in the Texture Import Settings lets you disable this feature on a per texture basis in order to access the texture data from a script using GetPixel etc.
• Improved iPhone script call optimization
• Removed unused parts of Mono runtime
• Reduced memory overhead while reading data from disk and slightly improved load times.
• Support for several predefined splash-screens (portrait/landscape) for Indie version. Just rename one of the splash-screens in the output directory to Default.png
• Exported audio session activation/deactivation functions to AppController.mm
• Added Scripting Reference code examples for iPhone specific APIs

Bug Fixes

• Fixed audio to play correctly after phone call / text message / alarm interruption occurs
• Fixed compressed audio occasionally refusing to play
• Fixed AudioSource.PlayOneShot to work correctly with compressed audio
• Fixed audio to respect Mute switch and background iPod music
• Fixed Pause function and time property for compressed audio clips
• Fixed OpenAL memory leak
• Fixed PhysX memory leaks
• Fixed Audio and Animation assets leaking while loading new scene
• Fixed a crash related to playing compressed audio in a sequence
• Fixed memory leak while updating Mesh geometry data
• Fixed several small memory leaks in rendering module
• Fixed asynchronous .NET sockets
• Fixed .NET threads
• Fixed cross thread boundary calling to the delegates
• Fixed UnityEngine.TextEditor stripping
• Fixed GUI slider stripping
• Fixed GUI scroll view stripping
• Fixed IndexOutOfRange exception checking
• Fixed Boo.Lang.dll stripping
• Fixed occasional crashes of AOT cross compiler

Yogurt3D flash based 3d engine appeared recently and is another flash based 3d engine which is based on OpenGL called SwiftGL and is stated as open source.

The site mentions that OpenGL source can be converted to run in the engine.  You can do this now with Alchemy although it is in very early stages.  It is not clear if it is an automatic conversion or if it simply means it is similar in syntax and method signatures, objects etc.

I definitely will be watching and see how it progresses, there isn’t much other than a single post about the engine so far and no info on the api or sample code.  Looking forward to seeing more, the z-sorting is quite nice.  Doesn’t appear like collisions are there yet but it has a nice look.

Sometimes excellent toolkits come out of the blue like this such as Ffilmation (isometric flash engine) or Alternativa (flash 3d engine flash 10 focused) so you never know.

@bartek from everydayflash.com is an amazing 3d flash designer and developer.  The latest from everydayflash is a sample using MouseConstraint in JiglibFlash the 3d physics engine for all major flash 3d engines.

It is easy to see how the latest version of JiglibFlash with MouseConstraint will be heavily influencing flash games and applications very soon. This is a very smooth and quick demo that feels very responsive on the controls.  There are so many possible uses for JiglibFlash now that the MouseConstraint is available.  It will evolve further but this version seems ready to start integrating into many flash game and interactive ideas and projects. Even though it is still alpha it has been heavily cleaned up and a plugin system added by bartek for pluggable 3d render engines.  That is a huge step for 3d pipelines in flash.

Great work JiglibFlash team!

Google has a few things going for 3d in the browser, not just 3d but hardware rendering in the browser.  They previously had native client which allows you to run code via a plugin proxy with a sample running Quake.  They also had Lively which was a virtual world plugin that was shut down a few month after it started.

Now they are also making and releasing an O3D plugin that looks to be another way to do web 3d scenes and games although it is a very early stage. They appear to want to have an open discussion about how best to add hardware rendering to the web.  Their approach uses a javascript api to control the browser plugin and the O3D control is essentially just a renderer.

This won’t change anything now as Unity3D, Flash 3D pseudo engines, even Director 3D still are the top choices for games, apps, and interactives that need effects and possibly hardware rendering. But it is interesting that Google is essentially re-entering this debate after ditching on Lively and they must see some benefit to having a discussion about 3d on the web and 3d standards in general.  I know they have lots of models and tools with SketchUp and Google 3D warehouse so who knows maybe they will take it over by being standards, open and information based.

What is O3D?

O3D is an open-source web API for creating rich, interactive 3D applications in the browser. This API is shared at an early stage as part of a conversation with the broader developer community about establishing an open web standard for 3D graphics.

Get involved

• Download the plug-in (Windows and Mac) and explore the samples to see O3D’s capabilities. Linux users, see these instructions.
• Read the Technical Overview and Developer’s Guide to learn how to get started.
• Join the O3D developer groups to provide feedback.

One thing is for sure, 3d development is still old school proprietary lock in in most cases.  Working with 3d and tools like Maya, 3dsmax and others they have always been very non standard.  From file formats to interfaces to even basic movements, all different.  The general maths of 3d are the same and so should 3d pipelines.  Formats like COLLADA are nice because they are starting to open up 3d pipelines and content creation but COLLADA still has many porting issues.  FBX file format is another that is really useful and common making pipelines in Unity 3D, for instance, very nice. But it is owned and run by Autodesk who owns all the 3d apps (Maya, 3dsmax, SGI) and I am a bit leary of that method.  But in the end 3d pipelines and rendering will be somewhat standardized and maybe the web will be hardware rendered one day.  In most cases it is not needed, but for gaming, immersion, demos and other entertainment it could benefit heavily from a more standardized 3d pipeline and methods.

Well it appears ES4 path is dead officially and a new standard has been published replacing it, the ECMAScript Fifth Edition announced in Geneva, Switzerland and will be in place as fully tested and approved by all involved by the end of 2009. ES5 was previously known as ECMAScript 3.1 or an iteration of the ES3 standard that is what most JavaScript is based on in all browsers, and was previously competing with the ES4 newer standard that changed Javascript quite a bit but in many areas much better, in some areas it was bloated.

This revision of ECMA-262 will be known as ECMAScript, Fifth Edition. It was previously developed under the working name ECMAScript 3.1, which will no longer be used. ECMAScript is the scripting language that is used to create web pages with dynamic behavior. ECMAScript, which is more commonly known by the name JavaScript™, is an essential component of every web browser and the ECMAScript standard is one of the core standards that enable the existence of interoperable web applications on the World Wide Web.

ECMAScript Fifth Edition (ES5) was strongly guided by Crockford and Microsoft, which is different than the push for ES4 which is what ActionScript 3 is based on and was supported by Adobe and Mozilla.

However it seems everyone is happy and everyone is supporting this version to get things moving if you go by the ECMA Org quotes:

Industry Reaction

Brendan Eich, Mozilla CTO and creator of the JavaScript language, said “The Fifth Edition of ECMAScript makes real improvements based on browser innovation and collaboration in Ecma, which provides a solid foundation for further work in future editions.” Microsoft’s ECMAScript architect, Allen Wirfs-Brock, commented “We expect the Fifth Edition to benefit all web developers by helping improve browser interoperability and making enhanced scripting features broadly available.”

Peace.

I still have to read further into the ECMAScript 5 specification which was published, but there are some new interesting things.

One nice feature is the JSON object.  Right now you have to eval to use JSON in javascript in a browser but they now have JSON.parse(object) and JSON.stringify(object) which is standard and conveniently already wired into IE8 this way. This is based on the JSON2.js library by Douglas Crockford of Yahoo.

var jsObjString = "{\"memberNull\" : null, \"memberNum\" : 3, \"memberStr\" : \"StringJSON\", \"memberBool\" : true , \"memberObj\" : { \"mnum\" : 1, \"mbool\" : false}, \"memberX\" : {}, \"memberArray\" : [33, \"StringTst\",null,{}]";
var jsObjStringParsed = JSON.parse(jsObjString);
var jsObjStringBack = JSON.stringify(jsObjStringParsed);

Another feature is DOM prototypes which are useful and cool, which allow you to extend dom objects.

• Document Object Model Prototypes, Part 1: Introduction
• Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support

If you use javascript or are an actionscripter, not sure if Adobe will have ActionScript 4 go this way or if Alchemy has changed the flash player into a multi language VM now.  It will be fun to watch things progress but also if you are into javascript it seems this standard, ES5, will be it by the end of the year.  And probably since IE8 already supports it, in all new browser by then as well.  It will probably take 1-2 years before browser saturation makes this usable but if you are using standards that mimic this then there will be no change then, such as the JSON2.js library.

A quick roadmap was posted by Unity3d.com blog on the immediate future of Unity iPhone.  Currently I am developing two games for the iPhone OS 3.0 and these are welcome updates.  We are really looking forward to items not in the hard version just yet but we are looking forward to terrain support and downloadable content support in iphone sdk 3.0.

Unity iPhone 1.0.2. Based on custom builds we’ve been sending to devs in need, this release will address engine memory leaks and fix other outstanding issues:

• Physics and audio related memory leaks
• Asset leaks while reloading scenes
• .NET sockets and threads
• Compressed audio related issues
• Stripping away too much of GUI components
• Occasional crashes in AOT compiler
• Support for both portrait and landscape splash screens 

Next will be Unity iPhone 1.1. Since the release of 1.0.1 we’ve been working on a number of performance and memory optimizations. Most of the work on 1.1 is finished already and we’re doing an internal bug fixing round before it goes to beta testers too. Along with optimizations this release will include number of important features such as:

• Binding custom ObjectiveC/C++ functions to C#/Javascript
• Native on-screen keyboard support and interoperability with Unity GUI
• Movie playback support
• Performance optimizations:
  • significant C#/Javascript performance improvements
  • general rendering loop optimizations resulting in less OpenGLES state changes and less CPU work per object
  • number of internal routines were rewritten using VFP coprocessor assembly
  • way much faster mesh skinning utilizing VFP
  • batching small objects, given that they share same material, into single draw call

• General distribution size optimizations which allows applications below 10Mb
• Number of significant memory footprint optimizations

 
We don’t have strict versioning past 1.1 yet. Some of the following features will end up in the next big release and some might find a way to sneak into 1.1:

• Compressed audio streaming directly from disk
• Support for 3.0 SDK
• 3.0 downloadable content
• 3.0 bluetooth networking
• GPS/Location support
• Vibration support
• Post-processing and render-targets support
• Terrain support
• Per-pixel DOT3 lighting support for skinned meshes
• Reduce load times
• Reduce distribution size even further
• Improve GarbageCollector collection patterns to reduce spikes

Torque3D seems to have full featured browser surfaces that you can use in the 3d engine seamlessly, see the video below (at :38). This is amazing stuff.

Making games that integrate content from the web is especially required these days.  It is a difficult thing to do within the 3d render because of all the plugins, styling etc that needs to be rendered on a 3d surface.  Well Torque3D has a killer feature in that it supports entirely full features browser render on a 3d surface.  So now you can integrate html content, flash video etc in your game easily.

You can play content in flash player content easily and have stripped down html but it is limited, you can play videos and have content in Unity3d but it is limited, even larger engines like Unreal 3 have difficulty handling flash and html content.  If this is a good implementation Torque3D has a killer feature on their hands! Flash is commonly used as user interface elements and content within games but it can be challenging.  This is pretty exciting if it works as advertised. Think of how cool all the little consoles, mini-games and controls in 3d games could be in flash easily.

See at :38 in the video…

GDC 2009 – Torque 3D Web Demo from GarageGames on Vimeo.