I am (still) searching for tools to migrate from AS3 to HTML5: the main problem I need to understand and solve, whatever the tool I choose, is: how do I load external programs/assets from the main one?
In AS3 I can deploy multiple SWFs: when I run the main SWF it can load external SWfs, containing assets or even complete applications that can be put and rendered on the same stage as the one of the main SWF.
How can I do the same thing in Haxe/OpenFl when targeting HTML5? I can deploy multiple entities representing my components (i.e.: the main game, the toolbar, the subgames etc), but how do I run/load one from inside another one?
We need to keep components separate, as they are maintained by different coders: updating one component should not force recompiling all applications using it. Is it possible or I have to surrender and create a monolithic application?
I think, traditionally, people use different libraries, and compile them together, so you might manage it as multiple haxelibs or other abstractions (using “include.xml” files, for instance) then you compile it all together at the end. This could be done automatically with commit hooks, even.
However, I think there is more ground that can be won in terms of interoperability between applications, and using a modular approach of loading one application into another. The Lime “module” system is the underpinnings to a goal to eventually out-of-the-box support loading of one project into another. In HTML5, I’m also thinking about ways to compile without OpenFL/Lime in a project, and use an external openfl.js or lime.js, which I think would be good
This is a Lime project, but it loads OpenFL as a module. I’d like this system to be able to support external files as well, so loading this OpenFL module could be a separate binary or JS file, or perhaps it could be used even further to embed OpenFL content within OpenFL, etc.
I meant, not including Lime and OpenFL within your JS file, but putting them in external JS files as well. This would allow them to be shared among multiple projects on the same page or server, it could allow for better caching, and (potentially) could allow for better file compression, if the Lime and OpenFL source can be written for more aggressive minification, the same rules would not need apply to everyone’s other codebases
So right now, OpenFL would be just the one JS file, but if we split it out (to have a separate openfl.js file, similar to pixi.min.js), it might be helpful for file size.
Technically, you can embed multiple OpenFL projects on the same page, already, and if you use the Haxe “expose” meta data, you can expose methods from one and make it available to the other. I just want to do something that’s a little bit more official, and seamlessly integrated
Any headway on getting openfl to compile to separate openfl.js? I am working towards 4 separate openfl JS projects on same HTML page. I would guess that openfl adds 400kb (give or take) to each project.js So I would see a 1200kb drop is size?
In my test the generated openfl.js was 1.4Mo without compression.
For the PiratePig sample using the external openfl.js made it go from 1.3Mo to 82Ko,
and for DisplayingABitmap from 1.2Mo to 32Ko.
Both of them without compression.
With compression (yui) openfl.js is 1.2Mo,
PiratePig goes from 706Ko to 54Ko,
and DisplayingABitmap from 653Ko to 21Ko.
Note that I didn’t test with the minimized versions.
But with or without compression sharing an openfl.js file quickly adds up the more game you have,
also if an user already played one of your game he’ll have openfl.js in his cache and will only load your game.
@singmajesty I talked about the steps on slack but didn’t write them here.
From memory running this hxml is enough: https://github.com/ibilon/openfl-tests/blob/master/openfljs/lib/lib.hxml there’s problems of course from out of date defines.
It takes all the openfl package, it has a macro to exclude ApplicationMain and DefaultAssetLibrary since they are required to compile but must not shadow the ones from the compiled project. (2nd problem here if these files are out of date, but they could be copied by the lime tool so not really a problem)
This generate the openfl.js file which is then processed by OpenflJS.hx (-cmd haxe --run OpenflJS) to add the same code that would have been generated if we added @:expose to all the classes.