Loading components

#1

Hi,
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?

#2

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

#3

Please can you explain how Lime module system works?
Please can you explain what you mean when you say “compile without OpenFL/Lime in a project”?

#4

Here’s an example:

https://github.com/openfl/lime-samples/blob/master/HandlingInputEvents/Source/Main.hx

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

#5

I have very basic example made using Pixi, and the html is this:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="utf-8"/>
	<title>Pixi test</title>
	<meta name="description" content="" />
	<script src="libs/pixi.min.js"></script>
</head>
<body>
	
	<script src="Pixitest.js"></script>
</body>
</html>

It contains 2 js files, could this be a basic way to load external applications? It is not dynamic, but if you know what you need it could be an easy (temporary) solution.

#6

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

#7

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?

#8

I think @ibilon got it working in a test he made. I’m interested in this by default, for sure, if it does not create any regressions or issues?

#9

(also, regarding final size, have you tried lime test html5 -final? It should make the file size per-project smaller)

#10

Yeah, some progress on the horizon? Any alternative to expose method?

#11

With -final I get 487kb. With haxemin I get 457kb

With -final and haxemin it gets down to 396kb. So my estimate is probably wrong for how large openfl is. Still I would guess there would be a sizable reduction by modularizing multiple projects.

#12

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.

1 Like
HTML5 better code size reduction
#13

What were the steps to generate a working openfl.js? Was that under another topic? Thanks :slight_smile:

#14

I haven’t had the chance to look into it yet but maybe this will be helpful? https://github.com/elsassph/modular-haxe-example

#15

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

Then for a project to compile,
https://github.com/ibilon/lime/tree/openfljs and https://github.com/ibilon/openfl/tree/openfljs needed,
the html5 build call a macro and if openfljs is defined exclude lime and openfl (which makes code assuming they are available)
openfl.js is added (like a ndll) and if openfl.js is included before the game (though <dependency />) it works! :slight_smile:

@hoseyhosey I looked at it and it’s similar but more oriented for run-time on demand loading of module which is not our case since we always need openfl.