Asset library and pure Haxe preloader tool
After KukkerMan's idea we have started a Haxe/neko project aiming to be able to assemble flash9+ resource libraries. The tool will be easily compilable on both Linux and Windows (and supposedly Mac?) as it is written for the nekovm target with as minimal external library dependencies as possible.People will also be able to extend it via plugins to support importing their favourite formats into the library swf. So far we use it with success for importing png, jpg, alpha-masked jpeg images, binary data and mp3 sound into the asset library. As it turned out, the since far sought pure Haxe-based preloading is also possible via the tool. Read on for some insight!
(Edit: Don't forget to check out our latest article Preloading with Haxe and SamHaxe on the topic!)
KukkerMan does a nice work implementing the modular import system: The asset library is described with an xml file, something like swfmill's simple format. However, a separate configuration xml file describes which tags are handled by which import modules. For example, the image tag is currently handled by our default Image plugin, but you could easily change that in the configuration file. (By the way, KukkerMan had hard time trial-and-erroring how to use the poorly documented ImageMagick library, and is now considering to throw the whole code into trash and restart with a better library :)
About preloading with Haxe: I implemeted the Sound import module, currently with mp3 support and more to come. For that, the hxformat lib was extended with mp3 support (more to come of course). When testing the sound import, placing the DefineSound swf tag on the second frame of the asset lib made the flashplayer cry out loud. It had a SymbolClass exported. After experimenting, it turned out that flash requires (? correct me, I'm not an AVM2 insider) an AS3 class definition for resources with a SymbolClass.
But you can say: "Hey, I use an asset lib with Haxe and I don't write class definitions for my assets!" Well, that works because Haxe generates the class stubs for you if this is the case. "Ok, but then why did you get that error?" That happened because Haxe only generates these class stubs for resources on the first frame of the asset lib.
So basically if you can generate class stubs for those resources, you can put all your heavy assets on the first second frame, wait with Haxe code for the whole file to load (possibly displaying preloader gfx), and continue executing rest of the code once the whole file (or at least the required frames) are ready. How to generate class stubs?
- You can do that by hand, creating simple class definitions with a constructor calling super(), with Haxe. The stubs will be on frame 1, but they don't eat up much space.
- Or you can generate an AS3 code block along with the asset onto the frame it resides (frame 2 currently). I tried this and seems to work nice (not sure about generating a code block for frame1 would not collide with Haxe, I will have to research this later).
// ctx is the format.abc.Context
var cl = ctx.beginClass(_name, true);
cl.superclass = ctx.type("flash.media.Sound");
ctx.endSubClass();
ctx.finalize();
Here you may spot two differences from the standard lib. First, beginClass() has a second true parameter. With this I tell it to call the superclass constructor, resulting in the following code inside the method:
...
beginFunction([],null);
var cst = curFunction.f.type;
curFunction.f.maxStack=1;
if (callsuper) { // this block was added
op(OThis);
op(OConstructSuper(0));
}
op(ORetVoid);
endFunction();
...
Also, the endSubClass() method was added with the minor difference from endClass() that it registers the class name as inheriting from the proper superclass. This solution is not a general one, but is a good starting point for now.
As a bottom line, this tool would prove to be useful and is an interesting challenge, so I hope that we are able to have an initial release in some weeks time. In the meanwhile (or during the meanwhile, Brian? :) you can try to guess the name of the tool, you get three hints for this:
- Assets are not only important for flash developers, but also for whom?
- Let's hope that this friendly tool won't inform on you to the FBI ;)
- ???
Comments
Comment by Matus, on 09.07.16. 08:58
Cool news!!!
(btw isn’t there a typo? (first instead of second) you can put all your heavy assets on the first frame)
Comment by KukkerMan, on 09.07.22. 00:35
You’re absolutely right. It doesn’t make any sense to put heavy assets on the first frame and use a preloader anyway. :)
Typo corrected.
Comment by edA-qa mort-ora-y, () (URL) on 09.08.01. 18:34
Perhaps it might help you, the DHLIB has a Ruby script which reads a swfmill resource.xml file and produces the haXe definitions for all of the contained resources.
Comment by [ron], (URL) on 09.08.01. 23:51
Before we began writing this tool, we had a custom resource xml format, which we transformed into swfmill xml and haxe class definitions. Now the tool is able to generate proper as3 class definitions for resources into the asset lib itself. However what you suggest is a nice feature, and we may add support for it in an upcoming version (maybe not in 1.0, because KukkerMan is already bashing my head for incorporating too many stuff into the initial release – he doesn’t want the asset tool to be the second Duke Nukem Forever :)
Comment by edA-qa mort-ora-y, () (URL) on 09.08.02. 10:07
Alright, sounds reasonable. If you do need feel free to just take it from the DHLIB package on my site — it is just a simply Ruby script.
Let me know when you have a working first version and I can test it out — I have a project that needs it and have no interest installing the adobe tools.
Comment by [ron], () (URL) on 09.08.02. 13:09
We would like to based the tool with as few external dependencies as possible, so Ruby is no-go for now – but I’m sure that we will be able to manage writing out haxe class definitions ;)
Right now we are waiting for format.swf modifications to be reviewed and maybe merged, and adding the finishing touches in the meanwhile. I hope we can make a test release in one or two weeks.
Comment by Martin Quinson, (URL) on 09.08.12. 23:40
An Haxe asset handling solution is what I really need to get started with the toolset, so your work is more than welcomed.
However, I’m still unsure whether it will be a flash-only solution or whether it will be usable for the neko and cpp backends too. I was thinking of doing something similar to SuperPackMe in Haxe (transcoding the images to hexa strings at compilation time, embeeding the strings within the app and decoding them at run time).
What are your plans? Did I miss something obvious?
Comment by [KukkerMan], () on 09.08.13. 22:16
It’s a flash resource assembly tool so it’s output is an SWF file. It’s based on format.swf haXe library and runs on neko VM.
Comment by Martin Quinson, (URL) on 09.08.13. 22:31
I understood that your primary target was the flash backend of haxe, and that the tool itself was on the command line with neko. But I wanted to know whether your solution would be usable for the other backends too. Do you think it’ll be usable as is provided that ? Do you have any plans to increase the target backend? Any hints about how to do so if I find the time to help?
Comment by [KukkerMan], () on 09.08.15. 11:58
Ah I think I finally get it.
Well, we’re using neko mostly for file system access and loading neko primitives from .ndll files. It can easily be ported to cpp target for example. We’ll think about it.
Comment by [KukkerMan], () (URL) on 09.08.27. 19:45
SamHaXe (yes, that’s its name) is now available for testing. You can download it from here: http://mindless-labs.dyndns.org/trac/sam..
