Monthly Archives: January 2011

Corona SDK, a short stack


One of the elements that I most like about Corona SDK is that it is built atop a short but solid stack. Here are the elements:

Corona SDK Parts:

  • Lua 5.1 Interpreter – 110Kb interpreter
  • OpenGL ES 1.1 and 2.0 – The graphics hardware acceleration standard
  • Native Libraries – Injected at compilation depending on the platform
  • Not a ounce more!!!

The Lua 5.1 interpreter is written in C and is thus highly portable. It has been widely adopted within the gaming industry given it’s tiny footprint. The entire interpreter + vm + systemlibs + gc + coroutines + data types are implemented in ~110Kb and there are extremely few platforms where Lua doesn’t run today.  Given the footprint, it is easy to embed the entire interpreter within an application where the result with graphics and logic outputs a file 300Kb at the low end. As the entire vm is embedded within your application, you are only a compile away from adding in the latest features. Lua also brings in 10+ years of portable libraries to choose from LuaRocks, Lua-users Samples, and if you are really interested full source for the VM is openly available.

One of the big mental hurdles to get past with Lua is that interpreted does not mean slow. Here is a good set of benchmarks to look at. Lua is well within the required range of performance for interactive development. I would suggest spending all of 5 minutes looking into Lua performance and then forget about it. Lua 5.1 within Corona SDK is fast enough for any mobile application and hardware will only improve things moving forward.

OpenGL ES 1.1 and 2.0 standards allow you to get the most from your application graphically due to wide GPU hardware support. I have yet to see any smartphone not implement either of these two standards in GPU hardware for the past year. With a GPU accelerated graphics you can push a ton of pixels at the screen before you see any sort of performance bottlenecks. Android 2.1+ and IOS 2+ have great implementations of these APIs and having Corona SDK standing atop them just means your app has all the graphics and video capability needed moving forward.

The Lua interpreter provides a means to integrate native API calls into the language easily. Depending on which OS you target different APIs are includes within your application at compilation time. This allows Corona SDK to expose native API’s to your application. Things like Native dialogs, graphics, fonts, audio, Box2D, In-App-Purchase, Camera, Webview, Accelerometer are all integrated into Corona with a simple API in Lua methods. This makes Corona very extensible as a platform allowing the core teams to integrate desired features in quickly. Since I have been working with Corona SDK the evolution of the platform has been very fast paced and the teams have gone to great lengths to let the community drive the platform forward, see roadmap.

Given that most applications using Corona SDK are 300Kb+, the productivity gains and cross-platform portability really hit a sweet spot for me. It is about as close to native development without the platform lockin, size limitations, vm dependencies, and performance limitations that plague other platforms for device development. If Corona were to add just two more platforms besides IOS/Android, say BlackBerry Neutrino(QNX) and Win Phone 7, I really think this platform becomes the next Flash for native device development almost overnight. Regardless of what it becomes, I am using Corona SDK on a daily basis for a large majority of my device development work.

Take an open look at Corona SDK, I am pretty sure you will like what you find.

Cheers,

Ted :)

Trees of Objects & Meta


Tree data structures provide the foundation for most interactive systems. In most cases one can take an existing app, class, or collection of objects and represent it with a tree structure. HTML, XML, JSON, DOM, Flash displayList, file systems, and programming languages are all hierarchical in nature.

I have been interested in serializing & deserializing tree based systems for a long time and feel like there is a gap in terms of file formats. Tag based formats (XML/HTML) tend to be fragile given closing tags and are generally hard to read and edit accurately without tools. Minimalistic formats like JSON and YAML lack type metadata and can be confusing to read and edit as well. Also parsers for these formats tend to lean towards generating a complete object hierarchy as a result vs emitting stream of events allowing a single pass of object generation.

Long story short, I haven’t found somethings that fits well and decided to build one. I settled on calling the format “Meta”. Here is the base definition:

Meta – A simple readable ASCII based format for typed tree serialization & deserialization.

The driving use case for Meta was storing levels of a game where you would simply clear the display list and generate objects representing a level of the game. The key was having an event based parser that allowed for type generation on a line by line basis. I tested this in JavaScript, ActionScript, Lua, and Python and in every case it was trivial to generate typed objects from a single .meta file. This is when I started to think about this as a file format and generally how the project came to mind.

Basics:

//comment
<NAME>:<TYPE>=<VALUE>
<NAME>:<TYPE>
	<NAME>:<TYPE>=<VALUE>
	<NAME>:<TYPE>
		<NAME>:<TYPE>=<VALUE>

Rules:

  • <NAME>,<TYPE>,<VALUE> are strings using any non-whitespace char, must quote if “:” or “=” is used.
  • Indention denotes object heirarchy
  • Types follows the colon “:” similar to type declarations in ActionScript 3
  • Values follows the “=” and vary in syntax to the type used.

Examples:

s1:String = "Hello"
n1:Number = 1234
b1:Boolean = true
//comment
innerobj:Object
	src = logo.png
	x : Number = 0
	y : Number = 0
	isFullResolution : Boolean = true
	rotation : Number = -30
	alpha : Number = 0.5
c1 : Color = #FF00FF55
an1 : Array = [1,2,3,4,5,6,7]
obj0:Object
	1:Number = 1
	2 = 2
	3 = 0
	4: Boolean = true
obj1:Object
	src = "logo.png"
	//comment
	x : Number = 0
	y : Number = 0
	isFullResolution : Boolean = true
	rotation : Number = -30
	innerObj:Object
		src = "logo.png"
		x : Number = 0
		y : Number = 0
		isFullResolution : Boolean = true
		rotation : Number = -30
		alpha : Number = 0.5

One thing I really like about the format is that it is streamable in that parsing of the file can start as soon as downloading begins, all you need is a complete line regardless of hierarchy. This makes it very useful for data exchange as sometimes it is handy to stream data(large array collections or ui) to a client. Within the game usage the format sets up large object trees of box2b enabled displayobjects (think of a level in Angry Birds…). Combined with a class that manages object creation/destruction/recycling and it gets really scalable. I especially like the readability aspect, just glancing at the file you can see the object tree and all you need is a text editor. Within the game engine I implemented Library and Reference types to allow for reuse of generated objects within downstream objects and properties. This sort of mapping made wiring up function handlers and material types far easier.

Obviously Meta is far from complete but I have found it very useful thus far. As soon as I apply a bit more polish to the codebase I will post the Lua and ActionScript classes for parsing and serialization.

Thoughts and comments always welcome.

Cheers,

Ted :)

Exploring Lua via Corona SDK


Last year I learned Lua as a new programming language. I got interested mainly due to its use as the primary programming language of the Corona SDK but also due to its use on other projects. Lua is used in World of Warcraft, Angry Birds, Adobe Lightroom and widely used within the gaming industry as a scripting engine atop a lower level 2d/3d graphics engine like OpenGL. Here is the basics from Lua.org:

Lua is a powerful, fast, lightweight, embeddable scripting language.


Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.

Corona SDK provides a 2d graphics API using OpenGL ES combined with Lua for building applications targeting iOS ( iPad & iPhone), Android phones, and Android tablets like NOOKcolor (Android 2.1 API7). The SDK has evolved with developer feedback to include many native device features (accelerometer/camera/webview) combined with fully hardware accelerated graphics/text and integrated with APIs for including physics (Box2d) and social (Facebook/OpenFeint). Long story short is that it is a great SDK for creating graphical interactive applications and games. Productivity is where Corona
and Lua really shine. Here are some code to get you thinking:
Create a new image and add to displaylist:

myImage = display.newImage( "image.png")

Draw a square and place it within a group:

local rect = display.newRect(0, 0, 100,100) 
rect:setFillColor(140, 140, 140) 
local group = display.newGroup() group:insert( rect )

Create some images and apply physics to them:

local physics = require( "physics" )
physics.start()
local sky = display.newImage( "bkg_clouds.png" )
sky.x = 160; sky.y = 195
local ground = display.newImage( "ground.png" )
ground.x = 160; ground.y = 445
physics.addBody( ground, "static", { friction=0.5, bounce=0.3 } )
local crate = display.newImage( "crate.png" )
crate.x = 180; crate.y = -50; crate.rotation = 5
physics.addBody( crate, { density=3.0, friction=0.5, bounce=0.3 } )

NOOKcolor and Corona SDK work great together. On Android, Corona is built atop the NDK (Native Development Kit) with graphics rendered to either OpenGL ES
1.1 or 2.0 depending on device support. NOOKcolor ships with a great GPU supporting both OpenGL ES 1.1 & 2.0 and thus graphics performance really shines. Corona SDK makes building more reading centric applications and games easy targeting NOOKcolor and provides for a solid foundation for cross-device development. As part of my internal work I am building a photo viewer for NOOKcolor with Corona SDK that can import from Flickr and other image services. The SDK makes quick work of this task given the pliability of Lua as a language. As a language is a a close kin to silly putty and executes very fast. At first it feels like Flash 5 ActionScript 1 but slowly you will find a subtle quality that makes writing Lua very enjoyable. I strongly suggest you take a look at Lua and Corona SDK, the language and toolset are a great to learn, know, and apply to your next project.

Cheers,

Ted :)

Hello World


First post on tedpatrick.com and thought a good “Hello World” seems appropriate. The plan is to pickup where I left off on onflex.org onflash.org and continue to share my thoughts on interactive software development. Having been blogging since 2001, the past few months are the longest break I have taken from writing publicly. My excuse lies somewhere between the birth of my son Jake, deprecation of FTP support on Blogger.com, and a new job working on the NOOK at Barnes & Noble but that is the end of excuses.

Onward Blogging!

Cheers,

Ted :)

Nookified


In July of 2010, I was invited down to Palo Alto to meet some engineers from Barnes & Noble working on a stealth project. I was shown a 3 inch ARM motherboard, a 7″ touchscreen, all wired up in parts on a table, and running Android 2.1. The device was heavy on GPU with a solid 800Mhz CPU, 256MB RAM, and a great touchscreen. Even in parts on a table, this device had real potential given how thin all the parts were and a measured battery life of 20 hours. At this point the discussion turned toward the possibility of getting Adobe AIR and Flash Player running on the device. Interesting…

Over the next few months I worked closely with the team to get early engineering builds of AIR Android running on the device and testing applications to find strengths and weaknesses of the platform/device. In hindsight, it was the highlight of 2010 for me and the best project I had worked on in a very long time. It is one thing to work on pure cross-platform software but quite another to tweak the OS and hardware to make a better user experience. Things began to return to normal as I began working on Adobe MAX until I was contacted via LinkedIn via recruiter.

The key that really got me was the content strategy surrounding NOOK. The device would ship at a $249 price point and really focus on selling high quality books, interactive content, and applications leveraging touch. I have long felt that the next big market was interactive, I based the last 10 years of my career on it, but the opportunity to help deliver that on a first class device & brand was extremely tempting. It was essentially an extremely well funded start-up and a chance for me to work on a mass market console for interactive software. Sold!

I feel strongly that in 2011 we are going to see devices fully embrace the interactive medium in a big way. Somewhere between applications and static books is a great new medium waiting to be explored.

In regards to AIR/Flash on NOOKcolor, we will save that for another day.

Cheers,

Ted :)