(ADMIN: Copied from another topic here: Lime preloader issue?)
Yeah … Doesn’t work.
Funny, I just assumed the EXE included everything … 
So, how do people distribute a game ? A whole bunch of folders with all the artwork just accessible to everyone ?
I have often thought, in addition to embed="true", that we should support some form of asset packing using the Lime tools. I worked on this today, and was able to get “Displaying a Bitmap” working using this addition to the project.xml:
<library name="default" type="pak" />
https://github.com/openfl/lime/tree/feature/asset-pak-library
Instead of writing to individual files, it writes to a single “default.pak” file. This still needs work, but I wanted to share that progress is being made, for everyone interested
Yes. asset packing is a great idea ! We definitely need something like that in order to make ‘professional’ games. (And thank you very much for working on it ! )
If I look at my build folder, I also see a lime.dll floating around. Is there a way to get that into our exe ? And what about the icon.ico ?
I would really love to have only an EXE + an asset pack for distribution.
It is possible to statically link Lime, so that you do not have a separate shared library, however, when you do so, we disable sound, because OpenAL is LGPL and “infects” your executable if it is statically linked (meaning all your code is required to be contributed as open source to anyone who requests)
So… that means that swf and air do not use openAL ? (I’m such a noob 
)
Adobe has a library embedded inside of Flash Player, probably using audio drivers directly, or some other library they may have paid to license. Adobe has agreements for video and audio codecs that allow them to distribute Flash Player and Adobe AIR (probably) for a large yearly fee that covers all their users. We are using open-source libraries, and are not paying for any licensed codecs or libraries. If someone would like to recommend an alternative to OpenAL for audio that’s a popular API, let me know. LGPL is good for library maintainers, but is bad for static linking.
On the bundled asset front, the latest sources for Lime and OpenFL support uncompressed, gzip and deflate compressed packed asset libraries, which should make assets a bit more secure. We could probably add encryption to this as well in the future. Instead of “assets/image1.png” or “assets/image2.png” it would be “lib/default.pak” with those assets all inside the one file
Thank you for explaining !
And yes, encryption for the art would be good to have, I think.