Lime, NME, and OpenFL


I’m just trying to get my head around these different but seemingly related projects. So it seems like OpenFL is an attempt to mimick the Flash render engine and everything else as much as possible, Lime is a light C++ layer to provide access to native platform APIs or something (and is maybe used by OpenFL?), and NME is just old?

It also looks like there is an older version of Lime on which OpenFL is currently based, and a newer one - is that what -Dnext is based on?

If I were making a mobile game with OpenAL and cocos2d-haxe, should I be using Lime instead of OpenFL? These are the kinds of questions I have. :slight_smile:


Kevin N.

1 Like

NME was sort of the original pioneer in being a Haxe library designed for desktop and mobile application support. The design of NME is primarily C++, with Haxe wrapping it to provide support for each native target. It by and large follows the Flash API, with some departures and some added features.

I was one of the lead developers of NME, Lime and OpenFL are sort of an extension of that work, but it takes a different approach.

Lime is designed to be used either by people who prefer to work lower-level (such as direct OpenGL calls) or to be used underneath a framework such as OpenFL. Most people can use OpenFL quickly and easily, but OpenFL benefits from the stability and portability of the Lime codebase.

The Lime legacy path originates from NME. This is the default currently for native OpenFL builds. Lime itself does not use this code at all, but the OpenFL “v2” code accesses it to render and generally behave in a similar way to NME, but unified with OpenFL’s other targets.

Otherwise, Lime is totally distinct. Lime creates a window, provides system events (such as mouse, keyboard and touch input) and provides access to rendering and sound, not only for desktop or mobile targets, but for HTML5, Flash and console targets (which is in the works). Over the Lime API, everything is consistent, besides the rendering, which is (by necessity) different between, say, canvas and OpenGL.

When you use the -Dnext flag, or when you use the Flash, HTML5 or upcoming console target, OpenFL is 100% Haxe code, written over the top of Lime. OpenFL used to have distinct HTML5 and native “backends”, but over Lime it is all unified now. I use “-Dnext” in order to allow both the older code and the new code to develop in tandem, heading toward the day when we switch entirely. If you wanted to develop a cocos2d-haxe library, it might be simplest to adapt to Lime (which is OpenAL + OpenGL on native) than OpenFL (which is the Flash API) but you can mix-and-match too.


This is very helpful, thanks!