Talk:OpenFL

OpenFL vs Haxe vs Lime

Written by Joshua Granick on 15 Jan

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.

~ google groups

Written by Hugh on 15 Jan

What NME "is" has not really changed since 2009 : http://gamehaxe.com/2009/04/07/hxcpp-nme-neash-released/

OpenFL was indeed NME when it forked at wwx2013, but since then has re-architectured and now, while it has many similar goals, it is a different code base.

Sharing a broad mission of "A flash-inspired API for cross platform development" OpenFL and NME differ in several technical ways.

- Nme is a single project, and opengl/flashless development is considered just one way of doing things that can easily be mixed with the flash way. OpenFL has a more formal distinction with separate Lime and Openfl projects. - Nme is smaller project with no dependencies. - Nme uses SDL_mixer, rather than the LGPL openal for destop audio. - Targets differ: NME has waxe, android-view, ios-view mingw-static-link while OpenFL has html5, tizen, BB and even console support. - NME has had a few features added since the split - Camera, StageVideo, Project-less compiling and OpenFl has its own new features too. - NME favours code stability over getting the architecture "nicer"

Currently, nme and openfl are close enough cousins that features can be ported from one to the other relatively easily if you are keen. But after openfl next this will probably not be the case. However, since they are basically compiling against the same API, there is a reasonable chance that code will work on both, eg "nme demo flixel:breakout" should work. This is likely to continue to be the case unless openfl adds some proprietary asset code, or similar, that is difficult to emulate.

From a personal point of view, I feel we have done all we can to reconcile nme and openfl/lime, but it not possible, especially with openfl next begin quite different.

So, I will not be moving to the openfl project, partly because of the name, but mostly because where the technical details differ, I much prefer the NME way. I seem to have lost most (all?) of the community, and this makes the communication side of things harder. NME is one of several projects for me, but I still have a few innovations planned, and I hope to rebuild a community of like-minded people who also feel NME is a great technical solution. And if no one else join in, I will still continue on at my own pace.

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on OpenFL. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.nme.io/about/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 12:45, 31 March 2016 (UTC)