-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue #35 by writing FlashEmbeddedAssetPackLoader and integrating hxswfml #267
base: master
Are you sure you want to change the base?
Conversation
…rating hxswfml into the build process. Since embedded assets load significantly faster than assets on the filesystem, this fix depends on @d29c102. To start embedding assets into flash projects, set embed_assets: true in flambe.yaml.
…fore continuing with the build.
… flash header during the build process.
…eader from the asset library. This change facilitates later using -D flash-use-stage to absorb the asset library's timeline so that assets can be stored in a frame after initialization code for the purpose of preloading. Also a few minor formatting fixes.
Great and long needed addition! |
Well, obviously the main reason for the filesize increase is that the assets are embedded in the SWF, where it used to be just code ;p Other than that, I'm not sure that the assets aren't compressed anymore. In my case, my assets directory is 7.6 MB and my SWF is only 8 MB. Which seems about right for assets + code. FWIW, I only have PNG's and MP3's. Do you see a bigger increase than that? What's the size of your assets directory vs. your standalone SWF?
That's a reasonable and probably doable idea if this turns out to actually be a problem, as long as the runtime cost of decoding isn't exorbitant. |
Without anything in assets folder (with embedding): 0.80MB If I exclude sounds I get 3.46MB total, but picture assets are just 1.28MB, giving us 1.38MB increase. |
It's from dead code elimination being disabled. If you don't do this, it doesn't work. It could definitely be a Haxe bug, and other Flambe users have reported a similar issue in #143 and #155.
I guess it could be, which is too bad since I think Flash IDE will store them compressed in the library. Your solution, of loading them as ByteArrays and decompressing at runtime is probably a good one. Another possibility would be to see if swfmill or SamHaxe behave differently. Anyway, I'd like to hear from @aduros before I spend more time on this, as it currently works well enough for my purposes. |
Hmm, I think DCE shouldn't remove anything from swf included via -swf-lib. What sort of problems did it cause? |
Is it possible to show a preloader when using embedded assets? |
Yes, actually, I did that in another branch that I haven't submitted a pull request for. https://github.com/purplepwny/flambe/tree/flash_preloader It's implemented in this game: |
Hey purplepwny! What can cause that errors? |
Since embedded assets load significantly faster than assets on the filesystem, this fix depends on my commit @d29c102. To start embedding assets into flash projects, set embed_assets: true in flambe.yaml.
I know you suggested resurrecting FlashAssetPackager in #35, but I see no reason to reinvent the wheel, and so bundled the Neko version of hxswfml into the bin directory for use by the build process.
It's actually unnecessary to copy the assets to the build directory if embed_assets is true, but if you don't, you lose the ability to have side by side HTML5 and Flash builds, as is made accessible by the default Flambe html scaffolding, so I've done it anyway for now.