Questions about working with assets

Hi!
I have questions about working with assets in OpenFL|Straling project.

  1. Why I need to place my assets paths to project.xml? What lime|OpenFL do with it?
<project>
    <assets path="assets/textures" embed="false" />
    <assets path="assets/images" embed="false" />
    <assets path="assets/sounds" embed="false" />
    <assets path="assets/fonts" embed="true" />
</project>
  1. I need load texture atlases and other images into my game. I use Starling AssetManager:
_assets.enqueue([
   Assets.getPath(PATH),
   Assets.getPath(PATH)
]);
_assets.loadQueue(onComplete, onError, onProgress);

If PATH is not present in projec.xml it does’t work.
What if I get PATH dynamically (from server or from iframe params) and I can’t add it to project.xml?

  1. Why I can’t load and use assets from everywhere like in AIR Starling version?)
    Seems I don’t understand something important)

Thx!

Adding asset paths to project.xml tells OpenFL which extra files you want to include when building your app. When you build an AIR app, you also need to pass extra files to AIR’s adt tool if you want to include them in the bundle (or, if you’re using an IDE, there will be a dialog somewhere that allows you to define which files you want to include). So it’s basically the same thing.

OpenFL can certainly load files from URLs that are not assets. If a URL isn’t an asset, then you can add it directly to _assets.enqueue() without wrapping it in call to Assets.getPath(). If it’s an absolute URL, like https://example.com/img/file.png, then it should just work, as long as you can load from that server. If it’s a relative URL, like ./img/file.png, then it needs to be from the same server as your .html file, and relative to that same .html file.

_assets.enqueue([
   Assets.getPath(path1), // asset
   path2 // not an asset
]);
_assets.loadQueue(onComplete, onError, onProgress);
1 Like

Thx a lot!

  1. [quote=“joshtynjala, post:2, topic:13715”]
    So it’s basically the same thing.
    [/quote]
    For bundle I agree. AIR pack assets inside output file. But why I need flag: embed=“false” ?
    <assets path="assets/textures" embed="false" />
    What task can it solve?

  2. About fonts
    <assets path="assets/fonts" embed="true" />
    It says lime to generate font files and @font-face section in index.html?
    So I can put that generated files everywhere in my server and change paths in @font-face?

Thx!

Here’s how I understand it.

If you use embed="true", OpenFL will automatically load the asset into memory at startup during the time when the preloader is displayed. When preloading is done, and your app is initialized, the asset will be available immediately when you ask for it from OpenFL’s asset system.

When you use embed="false", the asset is registered with OpenFL’s asset manager, but it will not be loaded automatically during the preloader. If you need it after the application starts, you need to request for it to be loaded (or request its path and use that path to load it manually, like you are doing with Starling’s asset manager). This usually requires adding some kind of listener and waiting for it to load.

That sounds like it should work.

1 Like

Thx!
Seems assets section in project.xml is needed at compile time to copy assets to bin directory, generate fonts. It helps with local launches and debug. But for production when you need to place assets anywhere or even in SDN it has no effect. You need manually to copy assets, change paths (for @font-face) and not use Assets.path in your code.
May be it helps someone.

I would guess that most people using assets with OpenFL probably don’t move files to different relative paths, or use a CDN. Definitely an advanced deployment situation.

If I needed to do either of these things, I probably wouldn’t use OpenFL’s asset system at all. I’d just load from URLs, both locally and in production. If I needed to get the files from a different URL while developing locally, I’d probably use conditional compilation to provide a custom domain names or root URLs for development versus production.