Node.js target for OpenFL is working now

[vroad]

Not all functions are working, but it's working now!

In openfl_next, Font rendering is implemented but not exported as a ndll function.

Since TextFields are not rendered correctly, please run original version of the demo to know what actually buttons say.

Rendering used to be much unsmooth with setImmediate(), but got better after using technique described in this page.

http://timetocode.tumblr.com/post/71512510386/an-accurate-node-js-game-loop-inbetween-settimeout-and

Node.js version of starling demo for windows:

https://www.dropbox.com/s/co09dm7d9dmuutp/starling_demo_nodejs_20141109.7z?dl=0

HTML5 port of starling demo:

http://vroad.github.io/starling-samples/

Original version of starling demo:

http://gamua.com/starling/demo/

Sources:

https://github.com/vroad/haxe/tree/nodejs

https://github.com/vroad/hxcpp/tree/master

https://github.com/vroad/openfl/tree/nodejs

https://github.com/vroad/lime/tree/master

https://github.com/vroad/away3d-core-openfl/tree/devel

https://github.com/vroad/starling-openfl/tree/master

[Brennan Kinney]

Bringing Starling over to Haxe/OpenFL is awesome, do you have any plans for FeathersUI? I've seen several efforts in the past to port Starling over that for some reason were unsuccessful.

I'm not understanding how Node.JS works as an OpenFL target though? Isn't that covered with HTML5/bitfive?

[Joshua Granick]

Hi!

I have integrated initial support for node.js into Lime, based on your work. Once it is working there, I would be happy to look at things at the OpenFL level.

I had trouble finding what externs you used in order to define things for Node.js, somehow I had missed that you had been using a custom fork and branch of Haxe, now it makes more sense. As a quick question, why do you use custom "node.ArrayBuffer" (etc) classes, rather than js.html.ArrayBuffer? Are those interchangeable?

With some changes, I got things working on my system, though I cannot use "js.Lib.load" as this does not exist in standard Haxe or in the "nodejs-std" library which I'm using for a system implementation. Looking deeper at your repository, you require the "node_ndll" module, where does this come from?

I'm also curious about packaging things up as an application. Does anyone have experience with standalone node.js? Is it possible to use some sort of default module name (like "default.js") and have the Node.js binary execute that automatically?

If we got this to work right, we could do cross-platform desktop builds with this

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

[Brennan Kinney]

I'm just starting to teach myself node.js, for packaging a standalone application that you can give to end users there is node-webkit. You can distribute a .nw file(zip) or as a native application for the OS, more info here: http://strongloop.com/strongblog/creating-desktop-applications-with-node-webkit/ . For development with just node.js you just do a commandline call like "path\to\node\node.exe(or PATH environment variable) path\to\default.js" and that'll run your app on node, would then open a browser/webview to connect to it.

[j...@justinfront.net]

jigsawx has node webkit target you just install the node webkit app on a
mac and then see my hxml. I don't think I used any externs for node as
it works with just normal js, but you would need some I expect for sys
stuff if integrating with webgl.

[vroad]

I've implemented most of functions on node.js.

Only thing I still couldn't get working is font rendering.

https://github.com/openfl/lime/blob/master/project/src/graphics/Font.cpp

https://github.com/openfl/openfl/blob/master/openfl/display/BitmapData.hx

Font functions are exported, but never used in Haxe side.

BitmapData.draw, which starling uses to render text, is still not implemented for native targets.

Are these functions going to be implemented in near future?

Typed arrays of node.js are almost same, but node's typed arrays can be constructed from node's Buffer.

Sorry I forgot to include node_ndll in first post. It can be built with node-gyp command.

https://github.com/vroad/node_ndll

[PSvils]

Just watching from the sidlines - isn't a node.js target simply exporting to javascript, which already exists?

[vroad]

No, this one only needs lime.ndll (and some small node modules) to work, not node-webkit.

[Joshua Granick]

Neat! I'm excited for if I get more time to take a look.

Yeah, if you consider JavaScript separate from the DOM, using the traditional HTML5 target with JavaScript runs in a web browser, either traditionally, or using something like node-webkit.

However, vroad has node.js working as the interpretor for an OpenFL project, running on top of our native binary code. This means that it's a native application window, just like a C++ or Neko build, but instead of using either language, JavaScript is running the code on top.

On Fri, 14 Nov 2014 06:36:13 -0800, vroad <xvr...@gmail.com> wrote:

No, this one only needs lime.ndll (and some small node modules) to work, not node-webkit.

[Philippe Elsass]

That sounds like an amazing approach - live reload on device during dev in the future maybe?

[Brennan Kinney]

I'm still a little confused even with Joshua's explanation, will there at a later date be more in-depth blog post that can make the differences/usage more clear? It sounds like node-webkit(native app window on desktop running on JS code?) Or is it not using a webview like node-webkit?

[Joshua Granick]

Alright, I'll try one more time, and feel free to ask if it's still confusing... it sort of is, but hopefully this will help! :)

Currently in OpenFL:

The C++ target == a native window (provided by lime.ndll) + a CPP application (compiled from Haxe source)

The Neko target == a native window (provided by lime.ndll) + a Neko application (compiled from Haxe source)

The HTML5 target == a browser window (Firefox, Opera, Chrome) + a JavaScript file (compiled from Haxe source)

The Flash target == a Flash Player implementation (browser plugin, AIR, desktop projector) + a Flash SWF file (compiled from Haxe source)

You might see how the C++ and Neko targets use the same lime.ndll, and are the same at that level. They are also (mostly) the same on the Haxe level, they are just compiled to different technologies. The browser is used instead of the lime.ndll in the HTML5 target, so that changes a lot of things. Flash is similarly different, since it runs on Flash Player, not a browser or the code inside the lime.ndll.

node-webkit is effectively identical to the above HTML5 target, the only difference is you are distributing a portable browser implementation -- it's almost the same as running in Chromium, except that it's easier to package as a standalone application.

The method vroad is using for node.js would be the following:

The node.js target == a native window (provided by lime.ndll) + a JavaScript file (compiled from Haxe source)

It would be the same as the C++ or Neko targets, but use JavaScript instead of either C++ or Neko for the application layer. Otherwise, it is utilizing the same code for creating a native window, binding into the platform, and so on. C++ has benefits over JavaScript for performance, but JavaScript has benefits over C++ for compile-time, for cross-platform support, or more easily distributing updates.

Why would this be cool?

Theoretically, you could test an application much faster than C++, building to JS (almost instantly) while still testing the same native window, sound, etc (we haven't left the native environment to run in a browser). We could support cross-desktop builds, so you could build a Mac app from Linux or Windows, etc. You could also use it for "live coding" where your application reloads the script when it changes in order to instantly test new changes to game logic, without closing and opening. There could be other benefits, such as another way to run OpenFL from a command-line (such as server-side processing tools).

On Fri, 14 Nov 2014 16:07:45 -0800, Brennan Kinney <brennan....@gmail.com> wrote:

I'm still a little confused even with Joshua's explanation, will there at a later date be more in-depth blog post that can make the differences/usage more clear? It sounds like node-webkit(native app window on desktop running on JS code?) Or is it not using a webview like node-webkit?

[Brennan Kinney]

Yeah that helps explain it a bit more with the separation of a view/window and the logic being handled with the compiled haxe source. I can sort of see the benefits the target provides compared to the existing ones, Cheers :)

My background is mostly from AS3/AIR dev, I've only played with Haxe a little bit but having been following it since mid 2012. From my understanding Neko was similar to Flash by running in a VM where C++ got better performance and other benefits by being native, however the C++ build had to be done on the OS you wanted to support?(But not for mobile such as Android via NDK?) I thought Neko didn't require you to be running linux/osx to build support for those platforms but perhaps rather than being like .swf/.air it's more like the packaged captive runtime builds for AIR? So with this node.js target it's a bit different than all these options? From what I understand it runs JS via the V8 VM but beyond that it's similar to a native build being able to use C++ or the command line and bridge communication to the V8 VM? The difference from node-webkit being that instead of just a webview we're getting a native window via lime.ndll...and this handles all the input/audio/visuals through things like SDL2?

Would such a target only benefit from Haxe source or would you be able to mix in JS libs with externs? Would you still be able to make use of a webview and the JS libs/frameworks that work with the DOM? Or would the performance not be so good that you'd be better suited to node-webkit or JS/HTML5 targets? Another bit is it's being described for development(build tools/live coding/etc) but also for production/deployment, I'm assuming that's two instances, where the packaged/deployed version doesn't have all that dev related workflow tools? Node-webkit has two forms of deployment right? One where the user needs node-webkit installed and another that is like AIRs captive builds where the runtime is packaged with the app/game itself(increasing filesize), would a node.js target be deployed in a similar fashion? Would the later captive build type be viable for cross-platform deployments? With AIR I don't think you can create captive builds for OSX/iOS on windows, and well linux support was dropped some time ago.

Also curious how debugging might work..

[Chris D]

Thanks for sharing that Joshua. So much like we have node-webkit, the Haxe target here would be more like node-SDL(openfl/lime). I imagine the SDL performance will continue to outperform WebGL, so as far as technology that supports things like live reloading, this has a great advantage, a promising target indeed. 

[Juraj Kirchheim]

On Sat, Nov 15, 2014 at 4:13 AM, Brennan Kinney <brennan....@gmail.com> wrote:

[...]

Would such a target only benefit from Haxe source or would you be able to mix in JS libs with externs? Would you still be able to make use of a webview and the JS libs/frameworks that work with the DOM? Or would the performance not be so good that you'd be better suited to node-webkit or JS/HTML5 targets?

This solution is more of a node-openfl than a node-webkit, because by default there is no webkit and thus no DOM. OTOH I've seen some openfl+webkit solutions floating around (through waxe IIRC). Who knows.

 

Another bit is it's being described for development(build tools/live coding/etc) but also for production/deployment, I'm assuming that's two instances, where the packaged/deployed version doesn't have all that dev related workflow tools? Node-webkit has two forms of deployment right? One where the user needs node-webkit installed and another that is like AIRs captive builds where the runtime is packaged with the app/game itself(increasing filesize), would a node.js target be deployed in a similar fashion? Would the later captive build type be viable for cross-platform deployments? With AIR I don't think you can create captive builds for OSX/iOS on windows, and well linux support was dropped some time ago.

Node is based on the V8 and Apple won't allow the V8 to run on iOS (see reason 2 here: http://programmers.stackexchange.com/a/198388/667). So you're a little limited as far as deployment goes. Given that with Haxe it is relatively simple, it's probably better to compile natively for mobile devices anyway.

 

Also curious how debugging might work..

I guess for now you can use anything available for node. This should be a good place to start: https://github.com/node-inspector/node-inspector

Best,

Juraj