WWX 2014 - Round Tables

[Raphael Harmel]

Hi

We are planning to organize 2 round tables at the WWX.

The validated subjects and ideas are:

1. Native platforms

• Which tools fit my needs between openFL & NME & Lime ?
  
• Why different projects, considering the fact that they have a common goal ?

2. Haxion plan, what's our future together ?

• What are the goals of each typology of Haxe users ?
  
• What are the common goals?
  
• How we can work more efficiently all together ?

The idea is (hopefully) to end up with actionnable conclusion for a maximum benefit to the Haxe community.

We wanted to share this with you not to start debating now (let's leave this for the WWX :), but rather so that any of you could bring their ideas to make these round tables the most interesting and effective as possible.

So if you have questions to add on these topics, or other orientation which could be interesting, feel free to share !

Raphael

Silex Labs

[Hugh]

I would actually like to start the debate now, so we can get the emotional issues out of the way, and focus on actionable decisions in the limited face-to-face time.  I believe if we can work out exactly what the issues are, then we can find *technical* solutions to make everyones life easier.

I would like to know why  lime and openfl could not simply use NME for the native components. It seems adding a "nme/lime" source directory would make nme pretty much a superset of lime.

The original arguments of separate projects with an "openfl-tool" are now moot, since you run openfl with "lime" now.  Why is this not "nme"?

Lime now combines the templates with the native code.  It should also combine the tool too so that you do not need to do synchronized releases, and so in effect become the original nme.

I think the openfl flash*.hx could be auto-generated from the nme  nme.*.hx files and therefore would never be out of sync, and all native bug fixes would go into nme .hx files.

To answer the reverse question, of why I don't abandon NME and move to lime/openfl, I feel that:

 - openfl/lime are forks of the original code, made with out any real consultation, and the obligation is not on me to move.

 - the split projects are technically wrong as far as synchronisation goes.  The .hx files need to updated at the same time as the .cpp files

- Code/file/project layout is too unstable for me to work with.  I hate breaking backwards compatibility, and I prefer files not to be in different places when I wake up in the morning.

 - I prefer the nme name to openfl.  Obviously, this is a question of taste, but I think a haxe conversion script can solve this issue to everyones satisfaction.

- I find the coding style very difficult to work with

Hugh

[Nicolas Cannasse]

Le 19/03/2014 05:49, Hugh a écrit :
> I would actually like to start the debate now, so we can get the
> emotional issues out of the way, and focus on actionable decisions in
> the limited face-to-face time. I believe if we can work out exactly
> what the issues are, then we can find *technical* solutions to make
> everyones life easier.

Just to inform the Haxe community: given the recent events and
misunderstandings around NME and OpenFL relationships, Haxe Foundation
has decided to step in and will make sure that all involve parties
discuss and work together in the best possible manner.

We were originally planning to do that as part of a meeting at WWX, but
we will process by email until then.

We will keep you informed once issues are resolved.

Best,
Nicolas

[David Elahee]

Since Hugh started the discussion and that sadly people don't seem to understand the reach of the choices that were made.

Motion-Twin official view :

This nme/openfl/lime story has just brought more confusion to the haxe users and the openfl fork made the situation worse than ever.

Disclaimer :

We totally understand why Hugh don't want to switch, why Joshua had to fork and why lime had to be created but the situation is much worse. A big problem of communication and little bit of misplaced pride, took over what once was the jewel of haxe power.The Cross Platform flash library.

Despite Hugh arguments, openfl is now much more interesting than nme since it has html5, openal, many fixes and tries to stick to flash spec.

BUT :

Now instead of a slow evolving lib (nme) we have 9 github projects that are interwinded ( hxcpp hxlibc nme openfl openfl-native openfl-html5 lime lime lime-native lime-tools), still slowly evolving, that are not really open source since having them fixed or contributing has a time lag of MONTHES…

Pragmatically, fixes are randomly applied and some new bugs are introduced faster that ancients are resolved.

The most stunning problem being :

- Oh there is a compiler bug/oddity

- Simon/NC fixes it on high level

- Hugh fixes on low level hcpp

- We wait Josh to merge into hxlibc

- We wait for the full lime/ openfl to mirror it

- We find a bug in the fix...repeat wash rince, the fix is several weeks to us.

Which makes a many ricochet for simple fixes...that is very frustrating.

Basically as a production structure we don't want to put our hands in this kind of thing. We just want to have our fixes available asap.

So brothers, You should all get your shit together. The situation is ridiculous.

Basically you provide :

- one cross platform cpp backend

- one cross platform build system

- one cross platform flash library parser/renderer

- one cross platform gl driver

Why not just simply provide these 4 project separated and well maintained without divergence ?

People who want gl do not want a flash capable lib nor a template build system etc...

So despite our great love to Hugh, Joshua, and Sven, Motion-Twin replies, "Come on lads you should really speak together like Raphael suggests because despite your technically awesome talents, your mis-communication are now harming the haxe world."

And yes, you can say you don't care about MT/Froggies advice but we are producing games everyday on a bigger scale with your tools and are actively listening what haxers think and we know a great bunch of them so our view is representative.

We are perfectly aware that this kind of discussion goes nowhere productive but since yall don't seem to talk each other, that should be said.

When openfl was born we were promised a industry grade process to fix/test/release games, we are far fetched from it.

Now some concrete proposals :

Opengl driver separated ( put under haxeFoundation supervision ? ).

It is not acceptable for issues about low level primitives to wait 8 monthes to be fixed because of one another agenda.

Hxlibc terminated and reinstated as a hxcpp fork :

If the need of such a fork is real, because it is unacceptable to need anyone merging Hugh fixes on an alienated code so that users can use them. Since openfl is a private company it has rights to privatise hxlibc, but we open source user being coerced into using it is just harmful, especially since it is not daily maintained.

Lime should use hxcpp by default :

Either we should not be coerced to use something we think is plainly a bad decision (albeit a reasonable choice ) Or it should be daily maintained

All in all Nme/Lime/Openfl should have a daily maintainer ( like what Simon does with the haxe foundation ) because current bug situation is just ridiculous.

The respective Lime / Openfl / Nme people should start working together not side by side.

In a near future, people will get tired of this petty war and everybody here involved will loose something (not us users obviously). 

You should all now understand the reach or your acts. When you rename/fork/miscommunicate/stop talking/documenting, there are hundred haxers hurt and thousand of bucks of hard worker days burnt.

Please start getting in your user shoes for the greater good.

Thanks for reading, we understand you might think this is a rant but it is not at all. 

We are doing fine by ourselves but are deeply worried that our common baby haxe does not have the cross platform abilities it deserves.

--

Motion Twin ( Indie game dev company, co-mother of Haxe )

[David Elahee]

@ncannasse Thanks

--
David Elahee

[Hudson Ansley]

Having a solution for xplat development using legacy swf (asset only) media is becoming more important than ever given that Adobe has all but officially announced that they are not going to bother developing Air to port to x86 Android tablets which are coming onto the market in larger and larger numbers. Rumor has it that the Nexus 8 will be x86.

My current project has a load of asset only swf assets that are loaded and played by our iOS/Android mobile apps and so far in my research, haxe offers the only alternative xplat mobile solution that will work well with swf media. 

I know there are *many* developers who are now getting the point that Adobe is abandoning xplat for Air (then what is the point of Air? but still that appears to be their position) and so this could be a really great opportunity for haxe, that is if this openfl/nme/lime issue can be resolved.

Regards,

Hudson

ps- here is the Adobe comment on a bug report requesting x86 android support in Air:

>>>>>>>>>

For everyone who are facing performance issues or crashes on x86 Samsung Tab 3 device.

Thanks for reporting the issue. Adobe AIR Runtime and applications built using AIR are ARMv7 based binaries and every Android device should honor the Filters on Google play including application architecture. For example – Lava Xolo, which is an Intel device doesn’t show up Adobe AIR and AIR based applications in Google Play. However, it looks like Intel based Samsung Tab 3 doesn’t respect this filtering and the AIR application experiences performance related issues on execution. By the time, we investigate the issue, developers are suggested to try out the capabilities based device filtering on their Google Developer console to exclude a particular device. Please follow Capabilities targeting section @ http://developer.android.com/distribute/googleplay/about/distribution.html

Thanks
Adobe AIR Team

<<<<<<<<

https://bugbase.adobe.com/index.cfm?event=bug&id=3651397

--
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.

[tom rhodes]

This surely is about more than names though?

I have to admit I was baffled when I that NME was continuing on it's own, I thought NME had "become" OpenFL. I think it can only be a bad thing that they both exist in the same space when collaboration would appear to make the most sense. The Haxe Foundation's efforts to start a discussion here and try and resolve this situation is a great thing to see and hopefully it succeeds.

Perhaps the Haxe Foundation could use some resources to "take over" the day to day running of a unified project? In order that such a valuable tool in the Haxe ecosphere develops in a way that is best for Haxe, and it's community, 

On 19 March 2014 17:42, Lars Doucet <lars....@gmail.com> wrote:

To be clear, I'm not advanced or senior enough in this community to have a valid opinion on how this should be resolved, but I feel can weigh in on one thing in what I think is a more or less objective manner:

For what it's worth, the NME name is very difficult to google:
http://www.google.com/search?q=nme

Compare this to OpenFL:
http://www.google.com/search?q=openfl

Since getting started is such a crucial thing for developers, I think being able to effectively google the core names of things is pretty important.

Obviously lime suffers from the same issue as OpenFL:
https://www.google.com/search?q=lime

--

[Tarwin Stroh-Spijer]

Sadly I agree that NME is very confusing to a lot of people (sorry Hugh) and it seems I've only started seeing haxe "in the wild" since the popularization of OpenFL - even if this is simply a naming thing it seems to make a big difference.

I'd hate to see the amazing work done by anyone on these projects go to waste though. Good luck with the discussions.

Long time NME fan.

[Confidant]

Kudos to everyone for keeping the debate very civil. Let's get this figured out!

[Axel Huizinga]

Am 19.03.2014 18:48, schrieb Tarwin Stroh-Spijer:

Sadly I agree that NME is very confusing to a lot of people (sorry Hugh) and it seems I've only started seeing haxe "in the wild" since the popularization of OpenFL - even if this is simply a naming thing it seems to make a big difference.

Looks like I don't get the point here.
Anyway I don't think its worth the effort to talk that much about names - let's focus on usability.

Cordially,
Axel

[Zjnue Brzavi]

NME has been a constant source of clever code, good steer and much respect over the years.
Indebted to all the original visionaries.

Zjnue

[Lars Doucet]

I do hope we can avoid getting bogged down in a name debate, too.

That said, we do need to think about obstacles to wider adoption, and being able to frame The Haxe/NME-Lime/OpenFL tech stack as "Open Flash" has been really helpful.

I've gotten a *LOT* of positive feedback from this (admittedly simplified) primer for newcomers:
Flash is Dead, Long Live OpenFL!
(admittedly a slightly inflammatory headline, mostly meant to grab the attention of people worried about ActionScript/AIR's future -- ie, a HUGE potential audience for HAXE converts).

Hopefully we can work out the library situation and get everybody on the same page, and make sure everyone gets the proper credit for their contributions to this wonderful technology.

[Hugh]

> I have to admit I was baffled when I that NME was continuing on it's own, I thought NME had "become" OpenFL. I think it can only be a bad thing that they both exist in the same space when collaboration would appear to make the most sense.

From my point of view, this is exactly the same as someone taking the haxe source code (under the MIT license) and rebranding it "openc#" and wondering why Nicolas is not making contributions to it, even though it is "a much better name".

But that said, I am happy for openfl to live on as a brand, but with a "using nme" relationship rather than a "replacement for" relationship. Like how stencyl uses a curated version of haxe rather than maintaining a rebranded "openc#" version.

Hugh

[Justin Donaldson]

On Wed, Mar 19, 2014 at 7:26 PM, Hugh <game...@gmail.com> wrote:

> I have to admit I was baffled when I that NME was continuing on it's own, I thought NME had "become" OpenFL. I think it can only be a bad thing that they both exist in the same space when collaboration would appear to make the most sense.

From my point of view, this is exactly the same as someone taking the haxe source code (under the MIT license) and rebranding it "openc#" and wondering why Nicolas is not making contributions to it, even though it is "a much better name".

To be fair, I think Josh took as much flack for the OpenFL name as you did for NME.  I think the naming issue is moot. 

I think the main question is:  should OpenFL try to cater so strongly to the flash refugees, or should it follow your ideas with NME?  NME seems to be moving away from strict compliance with some of the flash APIs.  I think the big issue there for flash refugees is to better understand exactly what is different.  I'm guessing that most developers would be happy with something that is 90% compatible in order to achieve greater cross-platform performance.

As a paid service, OpenFL has a better shot of documenting and communicating the process of an open source cross-platform game workflow to a wider audience.  That's something that most of us in the community want to see happen, but obviously all the stakeholders (you, Nicolas, etc.) have to be on the same page for it to really be successful.  Can't we focus on common ground there?  Is there an aspect of OpenFL (the code base or the organization) that might benefit NME?

Best,

-Justin

[Hugh]

There are a number of great things that openfl is doing that nme is not.  Eg, html5, community interaction and social media bandwidth.

I do not wish to duplicate these in nme. I do not wish for openfl to go away. I don't want anyones openfl code to stop working.  I want some constructive software engineering solutions so we only need to maintain one EventListender.hx implementation and one OGLExports.cpp file.

Hugh

[Juraj Kirchheim]

I think making things smaller is the way forward. I found nme to be an
unapproachable behemoth. It takes many, many decisions. OpenFL suffers
from the same issue. As a matter of fact, many of the Haxe UI
libraries do.

I am all for different approaches and for duplication, if it serves
exploring those approaches. But in many cases it doesn't, particularly
if too many solutions to entirely unrelated problems are being fused
into one. Obviously, the FlashPlayer API is vast (which it had to be,
with the runtime being deployed as a whole). But I think its
implementation should be composed from much smaller and more
manageable pieces.

We could just have a standalone event loop for haxe/cpp, that makes it
easy to run synchronous stuff in the background. With that it should
be possible to implement URLLoader on top of haxe.Http, rather than
having yet another duplication. We could have a haxe.Timer
implementation that depends on just that event loop. Waxe could have
an alternative implementation of that event loop that hooks into that
of wxWidgets (assuming that is possible).

There's so much amazing stuff in NME and OpenFL. I think it would be
great to cut some of it out. It's a little tragic that all this effort
is so interlinked with the decision to mimic the FlashPlayer API and
all the work that comes with that decision. Only so that most game
engines hide it under another layer of abstraction. And that much of
the functionality is reimplemented in h2d to be exposed through a
completely different API.

I am an outsider to all of this stuff. While I am awestruck by the
immense amount of dedication, work, patience and ingenuity behind all
these projects, I've always felt driven away by their size and their
NIH tendencies. I believe all these efforts could benefit more from
each other if some energy were put into sensibly dissecting them into
different components. Then, not only could the big projects more
easily benefit from each other, but the rest of the community could
also use just the parts that are relevant to them.

In any case, I wish you the best of luck in working this out ;)

Regards,
Juraj

[tom rhodes]

Hey Hugh,

I was baffled because I thought you were 100% involved in the new project! Not because you want to carry on a project you've created and loved and improved for years!

First and foremost this shoudl be about the best, most performant, most stable, tools for the Haxe community. Marketing is secondary to that IMO. My comments about not existing in the same space weren't to do with name space, I mean tecnical scope, aims, competences etc. I think in the long run divergence of these codebases will be a bad thing for Haxe in general.

[Joshua Granick]

Hi everyone,

I think we all agree that we love Haxe and we want great tools, and we don't want confusion.

We're talking offline to sort things through, thanks everyone!

--

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