The latest release of Moai SDK has some big additions to it. The first is integration with the virtual file system PhysFS. The second is an improved rendering engine that supports both OpenGL ES 1.1 and 2.0 as well as desktop OpenGL. The OpenGL rewrite was no small feat, but we’ve been able to add it with minimal impact to the Lua framework in terms of backward compatibility.

Here’s are some highlights of what’s changed. There’s a more comprehensive list in the release notes, and of course a full list in our github repo log.

- MOAIFont serialization - you can rip your fonts as part of your build process. - First pass of OpenGL programmable pipeline integration - First pass of PhysFS integration - Fixed GLUT bug causing processor over-use when in the background - Added support for offscreen rendering (MOAIFrameBuffer) - Added support for interlaced PNGs - Modified iOS sample host to create GLES 2 context with a fallback to GLES 1.1 - Improvements to untz (streaming sounds, fixes on all supported platforms) - Updated Flash jsfl export commants to handle offset registration points - Removed upper limit on props per layer PhysFS allows you to mount any .zip archive as a file system extension. This is a major improvement in Moai app deployment under the Android host. For now we’ve implemented PhysFS as an alternative file system. You can load data into the Lua runtime via MOAIFileSystem. Right now, PhysFS is separate from Moai’s internal file system operations, so if you want to use it you’ll need to first load your data into string and then pass them to Moai. In a future release, we will integrate PhysFS more tightly with Moai so this will no longer be necessary. The move to support OpenGL ES 2.0 brings with it GLSL shaders. Internally, Moai checks to see if the OpenGL context supports the programmable pipeline, falling back on fixed function only if none is available. To make this possible we undertook a fairly major refactoring of Moai’s rendering engine. If you looked under the hood of the original implementation, you probably noticed a fair amount of redundancy between the graphics classes in uslsext and those in moaicore. In our new version, the original uslsext classes were absorbed into moaicore and consolidated under the clearer (I feel) notion of a MOAIGfxDevice. The original Moai Deck objects now render with built-in default shaders, so no changes to scripts that use them are necessary. You can attach your own, custom shaders to Decks or Props. You can also use MOAIMesh, MOAIVertexBuffer and MOAIVertexFormat to create custom vertex configurations for use with your shaders. MOAISimpleShader is gone; now there is only MOAIShader. The color and blend mode provided by MOAISimpleShader have been absorbed into MOAIProp2D. MOAIShader represents a GLSL program with both a vertex and fragment shader. You can create custom Moai dependency graph Attributes on MOAIShader and bind them to your program’s uniforms. In this way you can animate shader parameters as you would any other Attribute in Moai. You can also attach any number of MOAITransform objects to your shader. Alternatively, you can configure Moai to map matrices directly from its CPU transformation pipeline to your shader uniforms. Another new feature (though not OpenGL ES 2.0 specific) is support for off-screen frame buffers. To use this feature, simply initialize a MOAITexture as an off-screen buffer and attach it to a MOAILayer2D. The layer will render into the texture every frame. Moai’s graphic engine still caches OpenGL state and only invokes the graphics hardware on an actual state change. As before, most geometry is queued in a vertex buffer maintained by MOAIGfxDevice and only pushed to hardware on a state change. As the Moai Deck objects perform their vertex transformations on the CPU, drawing to hardware is usually only necessary when a texture, vertex format or shader changes (or when the vertex buffer is full). There are still some new features to be added. For example, more options to control how MOAILayer2D renders its contents. Right now, contents are sorted by priority and rendered with no depth buffer. We’ll be adding other sorting schemes (sort by X or Y axis, sort by shader and/or texture id, etc.) and the ability to turn sorting off (using the depth buffer instead). We also need to support configuration and use of OpenGL’s stencil buffer. A contributor called to my attention the fact that more than a few devices require the OpenGL context to be destroyed and recreated. We’ll be adding support for this behavior soon. If there is anyone currently blocked on this, let me know. As you experiment with this new release, please remember that it’s our first after some pretty aggressive changes. We’ve tested it against all of our samples on a number of devices as well as our internal games in development with good results. That said, YMMV, particularly on Android hardware. As always, feedback and bug reports are appreciated.