When adding -lib flixel to an OpenFL yeoman generated haxe project (except with the node_modules haxe uninstalled and using global haxe the path), with the latest Beeblerox HaxeFlixel branch and OpenFL 7.0.0 I get this error:
C:\HaxeToolkit\haxe\lib\flixel\git\flixel/FlxG.hx:244: characters 40-53 : Type not found : HTML5FrontEnd
at ChildProcess.exithandler (child_process.js:270:12)
at emitTwo (events.js:125:13)
at ChildProcess.emit (events.js:213:7)
at maybeClose (internal/child_process.js:921:16)
at Socket.stream.socket.on (internal/child_process.js:348:11)
at emitOne (events.js:115:13)
at Socket.emit (events.js:210:7)
at Pipe._handle.close [as _onclose] (net.js:549:12)
@ multi (webpack)-dev-server/client?http://localhost:8080 ./build.hxml
Using the standard build system it works, and with the NPM workflow it also works if I don’t add HaxeFlixel such as if I add other libraries to the build.hxml such as -lib hscript works.
It appears only to be HaxeFlixel + NPM/Webpack build system which has this issue.
When we build (using the Haxelib release of OpenFL), we have our own command-line tools, which may have certain behaviors (such as defining -D html5 or -D web on the HTML5 target) or (in this case) I think the extra behavioral difference is the use of “include.xml” files.
When using the Lime/OpenFL command-line tools, we process “include.xml” files automatically. This is not done using plain HXML, so it may need to be adapted by hand:
It looks like you may need to load some assets in order for Flixel to run (at least in debug mode) and also add --macro flixel.system.macros.FlxDefines.run() to your HXML. You may also be able to define some of these values yourself, instead of running the macro.
We don’t expose the Lime API on NPM, because a lot of Lime features require Haxe to work well (generics, abstracts, macros) but OpenFL has been pretty good in this regard since the original Flash API is designed for ActionScript, which is an ECMAScript language like TypeScript or JavaScript, so its built with certain limitations/features in mind.
I don’t know if Flixel leverages the Lime API, but that might be a concern
So I tried building again with this configuration:
-main App
-js src/app.js
-cp node_modules/openfl/lib
-cp src
-D source-map
-cp C:/HaxeToolkit/haxe/lib/flixel/git
-D flixel=4.3.0
-D lime=6.0.1
-D openfl=7.0.0
-D js=true
-D html5=true
-D web=true
--macro flixel.system.macros.FlxDefines.run()
And as you predicated the first error that showed up was “concerning” calls to the Lime API.
C:/HaxeToolkit/haxe/lib/flixel/git/flixel/system/frontEnds/BitmapFrontEnd.hx:13: characters 7-30 : Type not found : lime.graphics.opengl.GL
at ChildProcess.exithandler (child_process.js:270:12)
at emitTwo (events.js:125:13)
at ChildProcess.emit (events.js:213:7)
at maybeClose (internal/child_process.js:921:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
@ multi (webpack)-dev-server/client?http://localhost:8080 ./build.hxml
I’m not sure what can be done about this without possibly large modifications to the HaxeFlixel source, but I’m starting to think I might have to start making some difficult choices soon, such as switching to something like Phaser. Either way thanks for your swift reply, as always.
When we build the NPM release of OpenFL, it needs to support ECMAScript languages in general. This precludes certain Haxe-specific features, but Haxe + NPM doesn’t require us to build OpenFL in this way, per se.
I think we need more experimentation with -lib openfl instead of pointing to the NPM-style source, and figuring out what standard Haxe-based OpenFL needs to work better in this environment.
Have you looked at HaxePunk? I believe that supports the current version of OpenFL, and had a new release, just curious, what are some of the factors that may be driving you away from Flixel and/or OpenFL?
Well, I didn’t want to get into too much detail because I didn’t want my statement to sound like a dramatic “leaving of OpenFL”. There’s a good possibility I’ll come back to OpenFL in the future once I find things to be more stable out of the box.
I’ve actually been using HaxeFlixel and OpenFL for the past few years on some large, partially finished projects (with a lot of handmade art assets invested into them) and throughout its occasional kinks, pitfalls, and clunky neko build system, I’ve continued to push through due to my familiarity with the Flixel/OpenFL/Flash api and Haxe’s multiplatform features.
However, my issues with HXCPP externs lately have driven me towards a more completely JS-driven approach with Electron/Cordova and at that point, a great portion of the benefit of Haxe has been lost for me (effectively seamless, fast native builds on multiple platforms). HaxeFlixel has also struggled (in a significantly timely manner) to keep up with the latest OpenFL versions and Beeblerox’s branch is still unstable in many ways. With the increasing difficulties I’m running into along with many other issues I’ve run into over the years with Haxe’s ecosystem, this increasingly feels like the “straw that broke the camel’s back”.
While finding out that Phaser 3 is coming out literally today rebuilt from the ground up with a lot of interesting optimizations, features, and Typescript support (which Haxe externs also wouldn’t be difficult to generate after), I’m strongly considering just biting the bullet and porting my projects over as it’s API was originally based on Flixel (made by someone who contributed a lot to Flixel) and is still familiar in many ways.
Since I’ve already switched to Electron/Cordova builds and I’m writing C++ bindings in nodejs modules instead of HXCPP externs, it seems like a natural transition. It’d be difficult for me not to switch over without the main reasoning simply being sunk cost fallacy because at the moment the issues I’m running into are feeling as though they’re hindering my productivity rather than improving it (relative to other solutions).
I’d like to hear how Phaser works if you try it out, perhaps porting Phaser to Haxe (to run on Lime or some other library) might be a better approach long-term if someone needed native target support.
Have you been trying Cordova builds on mobile? How does the performance compare with native Android builds, using JS instead?
