Proposed patch for pure Haxe Flash 9 preloaders...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed patch for pure Haxe Flash 9 preloaders...

Ivan Stojić
(Resent as it seems that the mailing list software ate my first mail with attachments - the patch and example sources can be found at http://algis.hr/media/preloader.tgz)

Hello folks,

I'm submitting a patch for the Haxe compiler, specifically the Flash 9 output generator that would enable the implementation of one-file preloaders that Haxe/SWF game developers have so craved. I'm also including patches for the Haxe Flash 9 part of the standard library (to handle the new frame in the Flash output file, and different types returned from Lib.attach) and the OCaml swflib library (to support some currently unsupported tag types).


The idea of my implementation of the preloader functionality:

Create a new command line switch for the Haxe compiler, called -swf-boot-lib which takes the filename of an SWF library file as it's parameter. It behaves just like the -swf-lib, with a subtle difference. If you pass in the -swf-boot-lib, the output file will be slightly different: the code itself and the Haxe boot process will be initiated from the first frame, which will also contain the resources exported by the -swf-boot-lib. In effect, the -main class now becomes your preloader with resources in the -swf-boot-lib available to you immediately upon the start of execution. The content of the -swf-lib ends up in the second frame of the output SWF file. The standard library will also move the SWF playhead to frame 2 as soon as the load process is complete, so you can transparently start using resources via Lib.attach.

What does this mean? Your build process would be as follows: build a preloader library with swfmill, build the main data library with swfmill. Call Haxe in the following manner:

haxe -swf final-output.swf -swf-boot-lib preloader-data.swf -swf-lib main-data.swf -main my.game.Preloader

The result is a SWF file (final-output.swf in this case) which is a true one-file preloader.


I have attached a patch file that implements the proposed changes, diffed against the latest CVS state as of right now. The drawbacks of this implementation are as follows: it currently only knows how to process/import images files (TBitsLossless2 and TBitsJPEG2 frames) type of data and raw binary resources (newly implemented TBinaryData frame in swflib). What is conspicuously lacking is handling for any type of audio data, and fonts which I would first need to investigate further. With this patch, using either -swf-lib or -swf-boot-lib with resource types that are not supported will cause in a compile-time error due to the fact that the new compiler backend needs to rewrite all imported character IDs (to avoid collisions between the -swf-boot-lib and -swf-lib). Also, the files should export the resources via ExportResources tag, and not SymbolClass because that doesn't seem to work for some reason - this will work out of the box if you are using swfmill, but exporting SWFs from another authoring solution might not work. I'd love it if someone could suggest anything that I'm still missing in the codebase.

There are also two other classes attached to this e-mail: A Preloader, which is a base class for my preloaders and which offers some functionality which might be of interest (and an example how to create a generic preloader for your code), as well as a TestPreloader which is an example of how to use the Preloader class.

It's also possible that this patch will break existing SWF9 functionality, though I tested it with my own code successfully and extensively.

I'd love it if this could go into the main Haxe code base at some point. If there's any part of the code that is unclear, I'm open to cooperation and answering your questions either via e-mail, or on IRC.


I would like to appologize in advance for the code quality - I don't even know OCaml, I just hacked in the functionality. I'm sure there are bits and pieces missing, and I would love it if someone could help me out to finish what's missing. I'm also aware that the hacks look horrible, I merely wanted to get this in front of other people for someone to try to see/use. After a week at this, I need a few days of rest and I'd like to show it off first :-)


A great thanks is due to Jan, Mark and Madrok (whose real name I do not know) from the #haxe channel on Freenode, who helped me out with persistent, annoying motivational messages as well as providing example SWF files.





Ivan Stojić
Obrt za računalno savjetovanje "Algis"
http://algis.hr/

life is a low fidelity experience
http://www.ordecon.com/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposed patch for pure Haxe Flash 9 preloaders...

Kostas Michalopoulos
Ivan Stojić wrote:
> Hello folks,
>
> I'm submitting a patch for the Haxe compiler, specifically the Flash 9
> output generator that would enable the implementation of one-file
> preloaders that Haxe/SWF game developers have so craved. I'm also
> including patches for the Haxe Flash 9 part of the standard library (to
> handle the new frame in the Flash output file, and different types
> returned from Lib.attach) and the OCaml swflib library (to support some
> currently unsupported tag types).

As i told you via IRC, this is an awesome feature and i would like to
see it in the main haXe compiler too. Currently making a single-file
preloader (which is a /must/ i you want to distribute flash games to
many sites) requires a totally hacky method and a Flex installation
which i rather not have (well, i actually don't - currently i'm using
Mochi's preloader but at some point i might want to use a custom one).

> diffed against the latest CVS state as of right now. The drawbacks of
> this implementation are as follows: it currently only knows how to
> process/import images files (TBitsLossless2 and TBitsJPEG2 frames) type
> of data and raw binary resources (newly implemented TBinaryData frame in
> swflib). What is conspicuously lacking is handling for any type of audio
> data, and fonts which I would first need to investigate further. With
> this patch, using either -swf-lib or -swf-boot-lib with resource types
> that are not supported will cause in a compile-time error due to the
> fact that the new compiler backend needs to rewrite all imported
> character IDs (to avoid collisions between the -swf-boot-lib and
> -swf-lib). Also, the files should export the resources via

I suppose using a -swf-lib with unsupported resource types works just
fine if you don't use a -swf-boot-lib, right?

> I'd love it if this could go into the main Haxe code base at some point.

Me too :-)


If this is added, i would like to see -resource support for Flash fixed
too, ideally by using binary imports like SWFmill does instead of base64
strings. The current -resource implementation breaks (=crashes) some
Flash Player versions, especially for big resources, and generates
larger SWF files. At this point if someone (=me) needs raw binary data,
he has to compile a custom CVS version of the SWFmill.

Kostas "Bad Sector" Michalopoulos



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposed patch for pure Haxe Flash 9 preloaders...

Nicolas Cannasse
In reply to this post by Ivan Stojić
Ivan Stojić a écrit :
> The idea of my implementation of the preloader functionality:
[...]
> I'd love it if this could go into the main Haxe code base at some point.
> If there's any part of the code that is unclear, I'm open to cooperation
> and answering your questions either via e-mail, or on IRC.

First thanks for the patch : although it's not production-ready it's a
good start.

As you stated, the most difficult part when dealing with preloaders (or
more generally when linking several SWF libraries together) is that each
graphical resource is identified with an unique ID, and that ID is then
referenced in many different places, such as Bitmap FillStyle in Shape
drawing commands.

Thus, linking several SWF together is not easy. I have some code that
does that in one of our tool and I might extract it to haXe so that we
can support several -swf-lib, and then this will already one step
towards full preloader support.

But I was wondering if we couldn't go another way : thanks to the Flash9
API, we can load binary resources, so here's my idea of preloaders in
haXe :

- we have a preloader.swf, with 1 frame and some haXe code
- we append to this SWF a second frame with contains a Binary tag which
contains the bytes of the actual SWF content
- the source code of the preloader is responsible for waiting until the
second frame loads, then simply use flash.display.Loader.loadBytes to
initialize the SWF

I think that's an approach which is much more easy to deal with than
doing the linking of SWF files.

I haven't studied yet how Flex stores binary data in custom tags but I
would be interested in knowing more about that, that would save me some
research time.

Best,
Nicolas



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposed patch for pure Haxe Flash 9 preloaders...

Chris Hecker

It would be really good in the long run to be able to link multiple
swfs, though.

Chris


Nicolas Cannasse wrote:

> Ivan Stojić a écrit :
>> The idea of my implementation of the preloader functionality:
> [...]
>> I'd love it if this could go into the main Haxe code base at some
>> point. If there's any part of the code that is unclear, I'm open to
>> cooperation and answering your questions either via e-mail, or on IRC.
>
> First thanks for the patch : although it's not production-ready it's a
> good start.
>
> As you stated, the most difficult part when dealing with preloaders (or
> more generally when linking several SWF libraries together) is that each
> graphical resource is identified with an unique ID, and that ID is then
> referenced in many different places, such as Bitmap FillStyle in Shape
> drawing commands.
>
> Thus, linking several SWF together is not easy. I have some code that
> does that in one of our tool and I might extract it to haXe so that we
> can support several -swf-lib, and then this will already one step
> towards full preloader support.
>
> But I was wondering if we couldn't go another way : thanks to the Flash9
> API, we can load binary resources, so here's my idea of preloaders in
> haXe :
>
> - we have a preloader.swf, with 1 frame and some haXe code
> - we append to this SWF a second frame with contains a Binary tag which
> contains the bytes of the actual SWF content
> - the source code of the preloader is responsible for waiting until the
> second frame loads, then simply use flash.display.Loader.loadBytes to
> initialize the SWF
>
> I think that's an approach which is much more easy to deal with than
> doing the linking of SWF files.
>
> I haven't studied yet how Flex stores binary data in custom tags but I
> would be interested in knowing more about that, that would save me some
> research time.
>
> Best,
> Nicolas
>
>
>

--
haXe - an open source web programming language
http://haxe.org