Creating SWF Lib using Macros and Metadata

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

Creating SWF Lib using Macros and Metadata

Tarwin Stroh-Spijer
Hi,

I was wondering if anyone has used metadata and macros to create SWF libs. This would require the use of an external build tool such as SamHaxe to do the actual build itself. The idea would be to give a way to import images, audio etc in a similar way as it is done in Flex.

So, in Flex you write the following:

[Embed(source="logo.jpg")]
public var imgCls:Class;

You can then create an instance of this image:

var imgObj:BitmapAsset = new imgCls() as BitmapAsset;

We could then do something such as:

@embed({src: 'logo.jpg'}) public var img:BitmapData;

We would then run some kind of Macro that would call SamHaxe and create a .swf lib with all our assets to import. Having some trouble thinking how we actually tie it to the var properly, but may work. May have to do it more like Flex does where we create a Class instead, and actually specify it such as:

@embed({src: 'logo.jpg', lib: 'MyImportedBitmap'}) // on the class ?
public var img:BitmapData = cast Type.createInstance('MyImportedBitmap');

What do people think?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________

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

Re: Creating SWF Lib using Macros and Metadata

Simon Krajewski
Am 02.06.2011 20:57, schrieb Tarwin Stroh-Spijer:

> @embed({src: 'logo.jpg'}) public var img:BitmapData;

Building an asset .swf should be doable, did you consider using format
lib? However, I cannot see how you could actually bind the annotated var
to the new type without using @:build or @:autoBuild.

Also, building the assets .swf might slow down compilation considerably
unless you find a way to only reassemble the .swf when an asset file
changed. This might be possible by storing file modification times in
some special file.

Given there is a tool to assemble an asset .swf, this might be a lot of
work only to get
        @embed("logo.jpg") var img:BitmapData;
instead of the usual
        var img:LogoJpg;

Overall, I'd probably prefer a tool.exe myAssetFolder assets.swf to
generate an asset .swf, then using -swf-lib asset.swf and directly using
the class names from that .swf.

Regards
Simon


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

Re: Creating SWF Lib using Macros and Metadata

Tarwin Stroh-Spijer
Yeah, I agree the compile time would be a big consideration. The main reason I think this would be good is an encouragement for Flex users to use haxe. I know there'd be a larger percentage who'd say "but I can't embed stuff...".

Also, the current asset importing is not really good enough as it keeps binary info stored Base64 encoded, hence larger than needed and slower to load, than binary images / sounds etc.

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Fri, Jun 3, 2011 at 7:10 AM, Simon Krajewski <[hidden email]> wrote:
Am 02.06.2011 20:57, schrieb Tarwin Stroh-Spijer:


@embed({src: 'logo.jpg'}) public var img:BitmapData;

Building an asset .swf should be doable, did you consider using format lib? However, I cannot see how you could actually bind the annotated var to the new type without using @:build or @:autoBuild.

Also, building the assets .swf might slow down compilation considerably unless you find a way to only reassemble the .swf when an asset file changed. This might be possible by storing file modification times in some special file.

Given there is a tool to assemble an asset .swf, this might be a lot of work only to get
       @embed("logo.jpg") var img:BitmapData;
instead of the usual
       var img:LogoJpg;

Overall, I'd probably prefer a tool.exe myAssetFolder assets.swf to generate an asset .swf, then using -swf-lib asset.swf and directly using the class names from that .swf.

Regards
Simon


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


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

Re: Creating SWF Lib using Macros and Metadata

Simon Krajewski
Am 03.06.2011 00:18, schrieb Tarwin Stroh-Spijer:
> Yeah, I agree the compile time would be a big consideration. The main
> reason I think this would be good is an encouragement for Flex users to
> use haxe. I know there'd be a larger percentage who'd say "but I can't
> embed stuff...".

That's a valid point, and an embedding mechanism would certainly be a
start. But the main reason is probably still "but I have to type...".

> Also, the current asset importing is not really good enough as it keeps
> binary info stored Base64 encoded, hence larger than needed and slower
> to load, than binary images / sounds etc.

I'm confused, what are we comparing here? We currently import .swfs and
your suggestion was to generate and import a .swf as well, so I fail to
see the difference.

Simon


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

Re: Creating SWF Lib using Macros and Metadata

Tarwin Stroh-Spijer
On the first point: I thought the whole thing was that you didn't have to 'type'?

Second: I was comparing SWF import to Resources (http://haxe.org/doc/advanced/resources). Sorry I wasn't clear on that.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Fri, Jun 3, 2011 at 9:00 AM, Simon Krajewski <[hidden email]> wrote:
Am 03.06.2011 00:18, schrieb Tarwin Stroh-Spijer:

Yeah, I agree the compile time would be a big consideration. The main
reason I think this would be good is an encouragement for Flex users to
use haxe. I know there'd be a larger percentage who'd say "but I can't
embed stuff...".

That's a valid point, and an embedding mechanism would certainly be a start. But the main reason is probably still "but I have to type...".


Also, the current asset importing is not really good enough as it keeps
binary info stored Base64 encoded, hence larger than needed and slower
to load, than binary images / sounds etc.

I'm confused, what are we comparing here? We currently import .swfs and your suggestion was to generate and import a .swf as well, so I fail to see the difference.


Simon


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


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

Re: Creating SWF Lib using Macros and Metadata

Nicolas Cannasse
In reply to this post by Tarwin Stroh-Spijer
Le 03/06/2011 00:18, Tarwin Stroh-Spijer a écrit :
> Yeah, I agree the compile time would be a big consideration. The main
> reason I think this would be good is an encouragement for Flex users to
> use haxe. I know there'd be a larger percentage who'd say "but I can't
> embed stuff...".
>
> Also, the current asset importing is not really good enough as it keeps
> binary info stored Base64 encoded, hence larger than needed and slower
> to load, than binary images / sounds etc.

I'm planning "soon" to store resources into Binary sections of the SWF.

Nicolas

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

Re: Creating SWF Lib using Macros and Metadata

Simon Krajewski
In reply to this post by Tarwin Stroh-Spijer
Am 03.06.2011 02:18, schrieb Tarwin Stroh-Spijer:
> On the first point: I thought the whole thing was that you didn't have
> to 'type'?
>
> Second: I was comparing SWF import to Resources
> (http://haxe.org/doc/advanced/resources). Sorry I wasn't clear on that.

Ah okay, I never really used Resources. I was talking about using
-swf-lib with a .swf that was created by an external tool, e.g. SamHaxe
or the Flash Authoring Tool. This is already very convenient as you can
directly address symbols by their linkages/exported class names.

That's why I thought of a tool like SamHaxe that doesn't need .xml
input, but rather traverses a specified directory collecting all asset
files (.jpg, .png, .swf etc.) and exports them into an asset.swf with
their directory structure as package and their file name as class name.

Directory structure:
     assets
         img
             logoMain.jpg

Tool execution:
     tool.exe assets assets.swf

Usage in haxe:
     compile with -swf-lib assets.swf
     var logo:assets.img.LogoMainJpg;


This way it wouldn't slow down compilation and you retain full control
of your asset file structure. Mapping directories to packages is already
a known concept too, so I think this would be very intuitive.

Simon


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

Re: Creating SWF Lib using Macros and Metadata

Rob Fell


The key issues I face with "assets" are:

1) Runtime vs embedded (I want the choice to change my mind at any point
in the project for any asset)
2) Properly Typed (I want to be able to code against the members of the
asset safely)
3) Cross platform (I want to deploy my assets just once for swf and js,
possibly cpp)
4) Size & speed (I want to be able to load and instantiate assets rapidly)
5) Lossless to lossy compile time settings (I like to work with 24bit
pngs and deploy something slimmer)
6) Seamless audio loops that are also mp3 compressed (I like small
files, and I don't like gaps)
7) Arbitrary binary blobs (I want to use zips, md2, etc)

I don't want much do I?!?

The options I've explored (and how they scored in my evaluations):

SamHaxe / swfmill / hxswfml
Achieves: 1,2,4,7

Flash IDE
Achieves: 1,2,4,5,6

Flex SDK
Achieves: 1,2,4,7

haxe.Resource or other static bytes
Achieves: 3,7

I'd love one tool that rules them all, and I also believe that can only
come from extending haxe.Resource and using some embed style macro.  One
day maybe we'll write it ... but in the meanwhile I regularly combine
all tools available (achieving the same end result).

Best, Rob




On 11:59 AM, Simon Krajewski wrote:

> Am 03.06.2011 02:18, schrieb Tarwin Stroh-Spijer:
>> On the first point: I thought the whole thing was that you didn't have
>> to 'type'?
>>
>> Second: I was comparing SWF import to Resources
>> (http://haxe.org/doc/advanced/resources). Sorry I wasn't clear on that.
>
> Ah okay, I never really used Resources. I was talking about using
> -swf-lib with a .swf that was created by an external tool, e.g.
> SamHaxe or the Flash Authoring Tool. This is already very convenient
> as you can directly address symbols by their linkages/exported class
> names.
>
> That's why I thought of a tool like SamHaxe that doesn't need .xml
> input, but rather traverses a specified directory collecting all asset
> files (.jpg, .png, .swf etc.) and exports them into an asset.swf with
> their directory structure as package and their file name as class name.
>
> Directory structure:
>     assets
>         img
>             logoMain.jpg
>
> Tool execution:
>     tool.exe assets assets.swf
>
> Usage in haxe:
>     compile with -swf-lib assets.swf
>     var logo:assets.img.LogoMainJpg;
>
>
> This way it wouldn't slow down compilation and you retain full control
> of your asset file structure. Mapping directories to packages is
> already a known concept too, so I think this would be very intuitive.
>
> Simon
>
>
>


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