Newbie question, what's openfl for? and what they did actually?

[davy zhang]

I am pretty new to haxe, so far as I learn, haxe implemented most of as3 standard classes. openfl just re-implemented some of them to make it easy to adapt to other platform?

But haxe can already compile to ios/android/flash so what exactly did openfl lib do here?

Sorry if its a dumb question :D

[dlots]

OpenFL provides:

a wrapper initiating a rendering context
classes that mirror the Flash display list, by binding to third party scene graphs
binding to particular implementations to provide the functionality of the other Flash API facilities, sound, etc

on various operating systems. It implements this across the various operating systems by using the haxe compiler to generate code for particular targets, namely, native with C++, neko, javascript.

[Justin L Mills]

Openfl does not do much in respect to flash target and if you only want
flash target it's probably better to avoid it because your just adding
project complexity.

Haxe does not directly target android or ios rather it targets c++.

Some History hopefully this should be roughly right and maybe give you a
clearer idea of how it fits together.

Nicolas created Mtasc, then he rewrote it to not only compile flash but
also to his very light virtual machine running in c called neko to
replace PHP and also to compile to javascript, he called the language Haxe.

Neko could use the cffi to talk to pure c/c++ libraries
http://haxe.org/doc/cpp/ffi

Haxe Bindings for SDL were made using the cffi.

Lee McColl Sylvester ( one of the authors of the professional Haxe book
- the first haxe book ) created a library that emulated flash api for
the Neko target using SDL, I think it was originally called something
like Neko Media Engine then later neash but not sure.

http://code.google.com/p/neash/

the javascript version split off to jeash where Niel Drummond worked on
trying to emulate flash api in javascript not an easy task.

https://launchpad.net/jeash

At the about the same time Hugh Sanderson created c++ haxe target and
the sdl bindings could be reused for c++ and he added c++ to the neash
project.

Hugh got android and ios working with neash and Joshua joined him and
started adding more targets like Blackberry. By now Lee had mostly
stopped working on neash, and as Joshua started to take over it was
renamed to NME partially because of Neko Media Engine but now meaning
New Media Engine.

Then at the second Haxe conference Hugh and Niel met and they made plans
to reintegrate Jeash and the three of them added back the js target.

Joshua now renamed NME to OpenFL rebuilding many aspects to address some
of the install and operational aspects. Instead of being very similar
to the flash API he defined a sensible limited version of the flash API
and tried to make that replication more exact, some changes to Neko
related to 31 bit were such that it was much easier to keep the
interfaces exactly the same.

Joshua separated the cross platform ( ios, android, desktop etc... ) low
level emulation layer where differences are leveled, to the Lime project
with OpenFl now sitting on top with the flash api.

So it looks like the project was first checked in
http://code.google.com/p/neash/source/detail?r=2
back in Dec 2007, a humble minimal flash interface.

and has evolved to the stable solution you have today, where it can
seamlessly target multiple mobiles and desktop systems, and flash/js a
huge achievement. Lots of developers have contributed in it's creation,
sorry I only mentioned the key ones I know about, with Joshua now
heading up the team.

Hopefully that sort of explains?

davy zhang:

[davy zhang]

Thanks so much for your explainlation, This is a great help. And thanks to the great guys behind haxe and openfl, they really made the world better.

[Marc Weber]

http://www.openfl.org/about/overview/

While haxe can "compile" to the backends it doesn't mean it also ships
with code which can be used on all backends required to do useful
stuff..

Marc Weber

[Philippe Elsass]

That's certainly a big source of confusion: haxe.org says "your apps will support all popular mobile devices, such as iOS, Android, BlackBerry and more", and this is a damn misleading shortcut.

 

Haxe is a language and a compiler capable of generating code/bytecode for different targets, including C++.

 

But Haxe doesn't include any cross-platform API: each target has access to the target's API (Flash API for Flash target, DOM for Javascript target, etc.).

 

OpenFL or Kha are very complicated projects adding tools and a crossplatform game-orientated APIs to target desktop/web/mobile devices.

 

--
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/groups/opt_out.

--
Philippe

[Nicolas Cannasse]

> But Haxe doesn't include any cross-platform API: each target has access
> to the target's API (Flash API for Flash target, DOM for Javascript
> target, etc.).

Given the effort we put in having an efficient and cross platform std
library, I wouldn't say that we don't offer any cross platform API...
but you are right in the sense that we do not provide a cross platform
graphics API, only the logical part is provide by Haxe std, as well as
all the features that makes it possible to create one.

Best,
Nicolas

[dlots]

I agree with Nicolas. It's not misleading at all. A language std providing a 2d scenegraph is not a requirement or a particularly good idea as scene graphs have various goals.

On Saturday, January 25, 2014 11:11:37 PM UTC-5, davy zhang wrote:

[Philippe Elsass]

That's actually what I mean - if you say: with Haxe you can target everything and iOS/Android, people understand that you provide a cross platform graphics kit (and mobile packaging toolchain).

This adds confusion I think when you are selling a language capable of many more use cases.

IMHO Haxe.org should refer to other projects explicitly (OpenFL, Flambe, Kha) for people interested in the games/mobile aspect.

[Joshua Granick]

I agree with Philippe.

Through Haxe, you can support many *languages*

Through OpenFL, you can support many *platforms*

Haxe enables you to output native code, for use in desktop, mobile and web games or applications. OpenFL enables you to develop games and applications that automatically target Windows, Mac, Linux, iOS, Android, BlackBerry, Tizen, Flash and HTML5.

If you want to build a console application, Haxe may give you all you need (and through Neko, has been a powerful asset when development command-line tools), but if you are building a visual application or game (as most people expect on a mobile platform) then you need to provide your own windowing/rendering code, or adopt a framework like Lime or OpenFL.

Haxe gives you C++, and OpenFL gives you Android.

[davy zhang]

So, if the program stick with flash 2d graph api, it will run in other devices as it run in flash? What did cpp target use to do cross-platform graphic render?

So far as I understand, OpenFL build on haxe to compile and lime to abstract graph apis (using opengl ) for cross-platform multiple media. Just as LIME name suggest, Light Media Engine, just like SDL, but cross-platform support been made easy by haxe. Correct me if I am wrong, thanks.

[Nicolas Cannasse]

Le 26/01/2014 23:34, Philippe Elsass a écrit :
> That's actually what I mean - if you say: with Haxe you can target
> everything and iOS/Android, people understand that you provide a cross
> platform graphics kit (and mobile packaging toolchain).
>
> This adds confusion I think when you are selling a language capable of
> many more use cases.
>
> IMHO Haxe.org should refer to other projects explicitly (OpenFL, Flambe,
> Kha) for people interested in the games/mobile aspect.

That's what we will be doing with the new website.

Best,
Nicolas

[Saar Korren]

A simpler way to explain it is:

HaXe allows creating cross-platform logic code.
It also allows adding per-platform code for IO and other host-integration capabilities.

OpenFL provides a cross-platform graphics API, usable by HaXe code.
The API it offers is uniform, with roughly equivalent looks on any of the supported platforms (Give or take a window frame/HTML wrapper).

[Joshua Granick]

OpenFL (using Lime) adds two things:

- First, it adds command-line tools, to "build", "test", "run" (etc) against each platform, managing assets, packaging, install to various devices, etc.

- Second, it adds support for graphics, sound, fonts, networking (etc) for each target. On native, it's backed by a pure C++ backend. For HTML5 (not official supported ATM) it's Haxe compiled to straight JavaScript


Yep, the goal of Lime is to be sort of like SDL, but for Haxe projects, to "raise" the ground floor so we can innovate on more platforms/frameworks without going over the same stuff of platform support. OpenFL pushes that paradigm into the Flash API, rather than the lower level GL and Lime APIs