What's the status on NME and OpenFL?

[Pier Bover]

( Sorry if this has been discussed before, I don't visit this group very often. )

A few months ago I read about the new version of NME separated from OpenFL with new features such as StageVideo. Maybe I'm wrong, but at that time I was under the impression there was some sort of conflict between NME and OpenFL development, and that we would have more news of this by WWX2014.

What is going on in this front?

Regards

[Joshua Granick]

As you know, OpenFL was built upon on NME, and is spiritual successor. More recently, NME has come back with a newer release. The Lime tools are not compatible with both at this time, NME includes a different set of tools that are similar. We decided to pool efforts to develop a better C++ native backend together, Lime 1.0.0 and the current NME are both compiled from the same C++ source.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Using Opera's mail client: http://www.opera.com/mail/

[Pier Bover]

Thanks for the update Joshua.

With C++ backend do you mean the hxcpp target? Or a layer in between the hxcpp target and Lime and NME?

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

For more options, visit https://groups.google.com/d/optout.

--
Pier Bover
y...@pierbover.com

[Alex Hoyau]

> Lime 1.0.0 and the current NME are both compiled from the same C++ source.

So Lime 1.0.0 is a fork of NME? And it has nothing more?

[Joshua Granick]

In OpenFL, when you target C++ or Neko, there is a C++ layer (we call it a backend) that handles the SDL2 windowing, the OpenGL context creation, the Flash API rendering... ultimately, the bulk of what runs is hand-written C++, not Haxe, so we are sharing a common codebase, but compiling with different features.

When you target Flash, you have Flash Player as your "backend", and HTML5 is a different implementation than native. OpenFL ties these all together under one roof

[Joshua Granick]

Lime is not the same as NME, there are marked differences in functionality, but we tried in the last release to unify with NME so that we could work together more deeply.

I like to think of them as sister projects.

On Sun, 13 Jul 2014 05:37:57 -0700, Alex Hoyau <a.h...@silexlabs.org> wrote:

>> Lime 1.0.0 and the current NME are both compiled from the same C++ source.
>
> So Lime 1.0.0 is a fork of NME? And it has nothing more?
>
> On Saturday, July 12, 2014 5:33:22 PM UTC+2, Joshua Granick wrote:
>>
>> As you know, OpenFL was built upon on NME, and is spiritual successor.
>> More recently, NME has come back with a newer release. The Lime tools are
>> not compatible with both at this time, NME includes a different set of
>> tools that are similar. We decided to pool efforts to develop a better C++
>> native backend together, Lime 1.0.0 and the current NME are both compiled
>> from the same C++ source.
>>
>>
>>
>> On Fri, 11 Jul 2014 12:36:44 -0700, Pier Bover <pierb...@gmail.com
>> <javascript:>> wrote:
>>
>> ( Sorry if this has been discussed before, I don't visit this group very
>> often. )
>>
>> A few months ago I read about the new version of NME separated from OpenFL
>> with new features such as StageVideo. Maybe I'm wrong, but at that time I
>> was under the impression there was some sort of conflict between NME and
>> OpenFL development, and that we would have more news of this by WWX2014.
>>
>> What is going on in this front?
>>
>> Regards
>> --

>> To post to this group haxe...@googlegroups.com <javascript:>

[Hugh]

To understand the differences, you need to understand that there are several sub-systems interacting when you create a desktop or mobile app with NME or openfl.

1. The name of the project (NME vs OpenFL vs Lime)

2. The tool you use that runs the haxe command with the correct arguments, brings in the assets and copies everything to a directory structure that is needed by a specific target

3. Templates used to provide support files for specific targets (mainly ios, android)

4. The native C++ that does the vector rendering, opengl, curl, jpg, mp3 etc etc

5. The haxe library code that interfaces the native code to the developers code.

6. The 'hxcpp' haxelib support for haxe

Before wwx2013, these were all the same, in NME/hxcpp.

Then 1,2,3 and 5 were forked into separate projects.  Later 4 and 6 were also forked.

Before wwx2014, 4 and 6 were reunified.  I was hoping to unify 5 as well, leaving mainly superficial differences, but this looks like it will not happen now.

So I think it is (correct me if I'm wrong)

NME: 1, 2, 3, 4 (shared with lime), 5

Lime: 1, 2, 3, 4 (shared with nme)

OpenFl: 1, 5

So Lime is much closer to NME that OpenFl is to NME.  Lime is like nme with the haxe library files moved into openfl.  Of course, there are differences in implementations now - most notably that openfl also has html5 support.

For Lime 2.0, I'm not sure how it will work out - maybe a re-fork of 4, with:

   4.1 The native C++ that does the vector rendering.

   4.2 The native C++ that does opengl, curl, jpg, mp3 etc etc 

Meanwhile, I slowed NME development for a while, and then picked it up again to do the StageVideo stuff.  I could no do this in OpenFL because it required synchronised changes to the 2, 3, 4, 5 sub-systems, which were all in different repos for openfl at the time, while they were still in the same repo for NME.  Since then I think these sub-systems have been shuffled between several different openfl repos.

Personally, I greatly prefer the name NME, the single repo structure, the extra features and the stability of NME from one release to the next.  But then I would say that, and I respect that other people have other opinions.  And it does appear that NME has trouble competing with the openfl marketing power and as such I think I am the only one working on 2, 3 and 5 for NME.

Hugh

[Alex Hoyau]

Great thank you Hugh :-)

> The 'hxcpp' haxelib support for haxe

I am do not see what this one is (sorry to to take some of your precious time, but I guess it is good to have this written here once and for all)

---

From: Hugh
Sent: ‎14/‎07/‎2014 07:44
To: haxe...@googlegroups.com
Subject: [haxe] Re: What's the status on NME and OpenFL?

--

To post to this group haxe...@googlegroups.com

http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Baluta Cristian]

Sorry if you'll slap your face hearing this question, what is the purpose of Lime in few words?

Sent from my iPhone

You received this message because you are subscribed to the Google Groups "Haxe" group.

[Hugh]

Alex, the 'hxcpp' haxelib bit is what you get when you use "haxelib install hxcpp", and is needed for compiling to the cpp backend.  For a while, openfl had its own version 'hxlibc', but this has since been merged back into a unified hxcpp.

Hugh